×

[PR]この広告は3ヶ月以上更新がないため表示されています。
ホームページを更新後24時間以内に表示されなくなります。


JDMプログラマで12F629/675に再書き込みできない問題


 PICが壊れてしまったのか?

 高機能なフラッシュタイプのPIC12F629やA/Dコンバータ内蔵の12F675が国内でも安価に入手できるようになってきました。このPICとJDMプログラマ、IC-Progがあれば、低予算で電子工作がたのしめそうです。ところが、ここで難問がもちあがりました。ROCさんのホームページの掲示板でも投稿がありましたが、「IntOSCモードでPIC12F629(675)に書きこむと、次回から読み書きも消去もできなくなった」という問題です。

 FENG3は当初、マイクロチップ社のデータシートにVddが適用される以前にGP2、GP4、GP5に電源を供給してしまうと、PICがプログラムを実行して動き出してしまう、という記述があったので、それが原因だとかんがえていました。それで、JDMプログラマのオリジナルの回路では、GP4をVddに、GP5をGNDに接続するようになっていたのですが、FENG3のホームページで公開しているJDMプログラマの改良版では、GP4、GP5に何も接続しないであそばせておくか、GNDに接続するように以前からしていたのです。ところが、IntOSCモードでPIC12F629/675へのプログラム書き込みをすると、上記のような回路でも、次回から再書き込みがまったくできなくなる場合がでてきたのです。「PICが壊れてしまったのか?」と思ってしまいました。それで、改めてマイクロチップ社のデータシートにあたってみますと、PIC12F629/675のプログラミングでは、Vddが適用される前にVppが上昇してプログラミングモードに必要な電圧になっていることが必要だとわかりました。ところが、IC-ProgではPIC12F629/675に対応していても、JDMプログラマではVddをもともと制御できるようなつくりになっていません。JDMプログラマのばあい、IntOSCモードにしたばあい、MCLRがデバイス内部でVddにプルアップされているようなので、Vppが上昇するよりもさきに、というよりも、JDMプログラマにプログラムを書きこんだデバイスを挿入してPCと接続した時点でVddが適用されて自動的にリセットがかかり、内蔵クロック、プログラムカウンターが動作しはじめて、プログラムコードを実行することになります。つまり、PICが壊れてしまったのではなくて、PICライタのほうが再書き込みに対応していなかったわけです。もちろん、再書き込みできないだけで、PICには1回目のプログラムが書きこまれています(すべての場合ではありません。ねんのため)。しかし、このままでは、12C509AなどのワンタイムプログラミングのPICとかわりません。フラッシュタイプなのに、プログラムの再書き込みはおろか、プログラムの読みこみもできなければ、価値は半減してしまいます。

 JDMプログラマは非力なのか?

 JDMプログラマは、とてもよくかんがえられたPICライタで、シリアルポートの信号線から電源をとるため、外部電源不要で、しかも少ない部品点数で安価にこしらえることができます。これと、書きこみソフトであるIC-Progと組み合わせれば、最新のデバイスにも対応できる、はずです。しかし、上記の問題については、IC-Progの作者も作者の掲示板で「JDMプログラマのように電源電圧をきりかえることのできないプログラマでは、PICはすでに動作をはじめており、読みこみ・書き込みで失敗する。ほかのプログラマでためしてください」という内容のコメントを書いています。それでFENG3も電源を制御できるPICライタをこしらえようと、IC-Progで対応しているパラレルポート接続のPICライタを数台こしらえたのですが、いずれもライタ自体が動作しませんでした。原因は、FENG3のパソコンのパラレルポートが壊れていたからでした。

 つぎに、アナログスイッチ(4066)をJDMプログラマにとりつけて、Vddを制御できるようにしてみました。すると、読みこみができるようになりました。でも、再書き込みでエラーがでてしまいました。アナログスイッチの応答時間は、Vddの適用を遅らせるのに不向きなのか、それとも流せる電流がすくなかったのでしょうか。よくわかりません。つぎにJDMプログラマでためした方法は、GP3を抵抗でVddにプルアップすることです。この方法でも、読みこむことはできましたが、再書き込みはできませんでした。

 解決法がみつからないで考えあぐんでいたころ、トランジスタを2個つかってVppのオンオフでVddをスイッチさせてみると、再書き込みができるようになった、というメールを「シロ」さんからいただきました。さっそくためしてみたところ、みごとに読みこみ・消去・再書きこみができるようになりました。でも、トランジスタで回路を付け加えるのは、部品点数が増えるということもありますが、電子工作初心者のFENG3にとっては、自分ではライタが動作するから納得しても、いざ回路図を公開するとなると、抵抗の定数など自信がまったくありません。

 それで、GNDを相対的な+5Vの基準電圧にしているオリジナルのJDMプログラマではなくて、3端子レギュレータをつかったJDMプログラマにトランジスタの回路を付け加えてみました(写真下)。12F629、12F675をつかったテストの結果は良好でした。

 PIC12F629/675に完全対応するようにJDMプログラマを改造する

注意! 下記の改造をすると、12C5xxなど他の8ピンPICには対応しなくなるばあいがあるかもしれません。FENG3が12C509Aでテストしたところ、1回だけ書きこみでエラーがでました。2個目以後はエラーはでませんでしたので、原因はソケットへの差し込み不良など他にあるのかもしれませんが、他の8ピンPICで何度も書きこみエラーがおきるばあいは、デバイスの選択スイッチをとりつけてVddを切りかえるようにするか、12F629/675には下記アダプタで対応するようにする、という方法があります。

 上記の78L05をつかったJDMプログラマは、トランジスタ2個と抵抗を追加するだけなのですが、すでにJDMプログラマをこしらえた方にとっては、新たにライタをつくる必要があります。それで、いまあるJDMプログラマに少し手をくわえるだけで12F629/675に対応できるようにならないものだろうかと考えて、こんどは、フォトカプラをつかってVddをスイッチしてみることにしました。東芝の汎用フォトカプラTLP521-1(ランクはGB)を使いました。ながせる電流はPICのプログラム書きこみに必要な範囲ぎりぎりというところだとおもいますが、Vddの適用を遅らせるためのスイッチングの応答速度はちょうどよさそうです。下図がその回路の追加例です。フォトカプラの発光側の電流は、デバイスが要求するVppとVddの電流のバランスをとるために2.2kオームの抵抗R3をいれて制限してあります。また、発光側の発光ダイオードには、耐圧7Vをこえる逆電圧がかかる可能性がありますので、逆電流をふせぐためにダイオードD8を挿入しました。

 訂正 最初に公開した追加回路図で、VddがPICの端子につながったままになっていました(yu.linusさんからのご指摘)ので、お詫びして訂正します。yu.linusさんのホームページも参照してください(2003年11月16日)。

 訂正 18ピンのPICのVdd端子もスイッチさせてしまうと、16F84Aなどに読み書きでエラーがでることもまれにあるようなので、Vddと直結するように回路図を訂正しました。また、アダプタのほうも配線を訂正しました(2003年11月18日)。

 追加情報 フォトカプラTLP521-1は周囲温度の変化によって誤動作したり特性が大きくかわるばあいがあります。PICへのプログラム書きこみや読みこみ、消去などでエラーがでたり、読みこんだコードがおかしくなったりするときは、フォトカプラの発光側の電流制限抵抗R3を4.5kオームから4.7kオーム程度の抵抗にとりかえてためしてみてください(2003年12月3日)。

 トランジスタを使った回路の紹介

 トランジスタをつかってVddの適用を遅らせる回路が、IC-Progの作者のホームページの掲示板にさいきん投稿されていましたので、紹介しておきます。

 HOGEPIYOHAMU's Page

 トランジスタ1個とCRをつかってVddの適用を遅らせるかんたんな回路を海老原さんがライタの写真つきで公開されています。部品点数が少ないので、こちらもためしてみてください。海老原さんのご厚意により、個人的な日記のページに直接リンクしています。

 えびめも

 上記えびめもで紹介されている回路をアラムさんがJDMプログラマに挿入できるアダプタにされました。回路図 作例写真1 作例写真2

 VDD遅延回路をつかったライタでのトラブル(2003年12月9日)

 上記Vddの遅延回路をつかって、PIC12F629へIntOSCモード(MCLRオフ)でプログラム書きこみしたのち、デバイスを消去すると、プログラム再書きこみで失敗し、さらにデバイスを読みこんでみると、「0」で埋め尽くされたようになり、復旧できなくなる、という事例があります。くわしいトラブルの状況については、yu.linusさんのホームページをご参照ください。

 ここでは、FENG3がこのトラブルをまず再現してみようとおもいます。

 1)まず、未書きこみのブランクのデバイスを用意します。Vddの遅延回路をつけたライタで、内蔵オッシレータのキャリブレーション値を読みとって、メモしておきます。

 2)コンフィグビットを、IntOSCモード、MCLRオフにして、プログラム書きこみを実行します。

 3)プログラム書きこみが正常におこなわれ、ベリファイでOKとなります(ここで、内蔵オッシレータのキャリブレーション値が正常に書きこまれていなくてもベリファイでOKがでることがあります。対処方法はこの章の最後のほうで説明します)。

 4)つぎに、デバイスの消去を実行します。プログラムメモリやデータメモリは消去されますが、コンフィグビットは、さきに書きこんだ設定のままになっているときがあります。

 5)さらにコンフィグビットもデフォルト状態にもどそうと、IC-Progの設定でI/Oの遅延をいろいろためして消去をくりかえしていると、下図のようになることがあります。

 6)以上で、再現することができました。

 この現象を、もっとかんたんに再現できないものか、挑戦してみました

 1)まず、未書きこみのブランクのデバイスを用意します。標準のJDMプログラマで、内蔵オッシレータのキャリブレーション値を読みとって、メモしておきます。

 2)プログラムメモリの03FF番地を「0000」にして、IntOSCモードでMCLRをオフにして、プログラム書きこみを実行します。

 3)IC-ProgでI/Oの遅延を最小の(1)にしてデバイスを読みこむと、上の図のようになります。

 以上で終わりです、というのはじょうだんです。

 デバイスがこんな状態になると、正直いって、おどろきますね。消去もできないようだし、再書き込みしてもエラーがでるし…。それで、なぜこうなるのかという原因の追求はあとでやるとして、こんな状態になったデバイスをデフォルト状態にもどす、つまり、ちゃんとデバイスの消去(Bulk Erase)ができるようにするには、どうしたらいいかということです。デバイスを復旧させることが先決ですので、FENG3はそのようにしました。

 デバイスを復旧させる

 「0」で埋め尽くされたデバイスをデフォルト状態に戻すには、ちょっとした「テクニック」が必要です。

 まず、標準のJDMプログラマでの方法を紹介します。この方法は、デバイスにプログラムコードが書きこまれていないことを前提にしていますので、IntOSCモードでMCLRをオフにしてプログラムコードを書きこんだデバイスにたいしては、PICが動作をしますので、おそらく有効ではありません(消去できたようにみえても、実際にはまったく消去されていません)。

 1)IC-ProgのI/Oの遅延を最大(40)にして、デバイスの消去を実行します。

 2)つぎに、I/Oの遅延を調節して(10程度)、デバイスの消去を実行します。

 つぎに、Vddの遅延回路をとりつけたJDMプログラマでの対処方法を紹介します。この方法は、実際にIntOSCモードでMCLRをオフにしてプログラム書きこみをおこなったばあいを想定していますので、プログラムの再書きこみをするときなどに直面するかもしれない現実的な問題への対処方法です。

 1)Vddの遅延回路をとりつけたJDMプログラマで、デバイスの消去を実行します。

 2)Vddの遅延を適用しないで(デバイスのVdd端子にVddをテストリードなどで結線する)、IC-Progの設定でI/Oの遅延を最大(40)にして、デバイスの消去を実行します。

 3)Vddの遅延を適用しないで、IC-Progの設定でI/Oの遅延を調節(10程度)して、デバイスの消去を実行します。

 原因はいったいどこにあるのでしょう?

 さて、PIC12F629/675にIntOSCモードでMCLRをオフにしてプログラム書きこみをしたのち、デバイスの消去をするとメモリが「0」で埋め尽くされるのは、いったいなにが原因なのでしょうか? 正直いいますと、FENG3にもほんとうのところはよくわかりません。わかりませんが、けっしてPICが壊れてしまったので、消去も再書きこみもできなくなったわけではないことは、たしかです。下の図は、デバイスを再書き込みしようとしてデバイスを消去したら、メモリが「0」で埋め尽くされたさきほどの上の図のPIC12F629を、IC-Progの設定でI/Oの遅延を調節して読みこみ直したものです。プログラムメモリの03FF番地が「0000」になっているのがわかるとおもいます。つまり、03FF番地にあるべきインストラクションとオッシレータのキャリブレーション値がそれぞれ「0」として書きこまれてしまっていたのです。なぜ「0」が誤って書きこまれてしまうのか、その原因はよくわかりません。Vddのみの遅延だけでなく、DATAやCLOCKも関係してくるのでしょうか。

 上の図のようになってしまうと、PICの内蔵オッシレータに依存したタイミング機構が正常に機能しなくなるのではとおもわれます(まちがっていたら、ごめんなさい)。英語だらけのPICのデータシートですので、英語の理解力にとぼしいFENG3にはよくのみこめないのですが、デバイスの消去時には、このタイミング機構が必要不可欠になっているのに、これが正常に動作しないとなると、消去もできないということになります。Vddを遅延させないようにして、IC-Progの側で遅延を最大にしてデバイスの消去を実行すると、こんどは、03FF番地が「3FFF」にもどります。この操作をおこなった直後の時点では、他のプログラムメモリやデータメモリのエリアはふたたび「0」で埋め尽くされます。そして再度、IC-ProgのI/Oの遅延を(10)程度に小さくしてデバイスの消去を実行すると、こんどはインストラクションと内蔵オッシレータのキャリブレーション値は消去された「正常な」状態ですので、デバイスが正常に消去され、プログラムメモリやデータメモリ、コンフィグビットの状態も正常なデフォルト状態にもどる……そんなことではないかと、電子工作初心者のFENG3は考えています。

 より確実に再書きこみをおこなうには…

 上述のように、FENG3が実地にためしてみた経験から、PIC12F629/675にIntOSCモードでMCLRをオフにしてプログラム書きこみをして、再書きこみや消去をするばあいには、JDMプログラマではつぎのようにすれば、より確実になるのではないかとかんがえています。

 1)ブランクのデバイスにプログラム書きこみをするときは、標準のJDMプログラマでおこなう(ベリファイでエラーがでることがあるが、気にしない)。

 2)1)でデバイスにプログラムが正常に書きこまれているかどうかを確認するときや、読みこむときは、Vddの遅延回路を使う。

 3)デバイスを消去して再書きこみするときは、まず、Vddの遅延回路を使って、デバイスの消去を実行し、ライタ上で動作するおそれのあるプログラムコードを消しておく。

 4)つぎに、03FF番地を消去するために、Vddの遅延回路を使用せずに、IC-ProgでI/Oの遅延を最大にしてデバイスを消去する。

 5)Vddの遅延回路を使用せずに、IC-ProgでI/Oの遅延を(10)程度にして、プログラムメモリとデータメモリ、コンフィグビットを完全に消去する。

 以上です(あぁしんど)。なお、「RCDライタ」では、このようなやっかいな問題はまだ報告されておりません(2003年12月9日現在)。

 ご注意! 上記の操作をおこなうと、IC-Progやパソコンがその後の操作でフリーズ状態になってしまうことがあるかもしれません。今回の事例だけにかぎりませんが、IC-Progを使用していてフリーズ状態になったばあいは、データを保存してからパソコンを再起動し、そののち、IC-Progのハードウェアの設定を初期化してIC-Progを再起動するか、WindowsのレジストリエディタをつかってIC-Progのレジストリを削除すると、復旧します。

 PIC16F6xx、16F8xxでも再書き込みできるのか?

 フラッシュタイプのあたらしいPICがつぎつぎと登場しています。それらのなかには、プログラミングにさいして、たとえばVddを可変させる特別なアルゴリズムをとっているものもあります。VddよりもさきにVppを適用したら高電圧プログラミングモードで、VppよりもさきにVddを適用したら低電圧プログラミングモードになる、といったぐあいです。8ピン以外のPICでも電源以外のすべての端子をI/Oピンに設定できるタイプも登場しているようですので、12F629/675でおきた問題と同様の、いやそれ以上の難問にJDMプログラマは遭遇するかもしれません。しかし、努力すれば、解決することができるかもしれません。あたらしいデバイスでも入手できしだい、テストしてみる予定です。また、みなさんからのご意見、ご感想、お叱りなど、FENG3は歓迎します。

 16F819での再書き込み問題の検証

 nyaoさんから、PIC16F819にIntOSCモードで書き込みすると、再書き込みができなくなるという報告をいただきました。正確にいうと、後閑さんのホームページにあるPIC16F819のサンプルプログラムを、FENG3のホームページで紹介しているゼロプレッシャーソケットでつくるPICライタ5号機で、MCLRをオフにしてプログラム書きこみをすると、次回から読み書きできなくなるが、なんどもデバイスの消去を繰りかえすと、再書き込みできるようにはなる、ということのようです。

 この現象を再現するのに、少々時間がかかりました。というのは、シリアルポート接続のPICライタ(JDMプログラマ)のすべてのタイプでおきるわけではないからです。また、おなじタイプのライタでも、再書き込みできるばあいとできないばあいがあって、一様ではなかったからです。

 まず、ゼロプレッシャーソケットタイプのPICライタ5号機で、この現象を再現してみました。MCLRをオンにしてプログラム書きこみをしたばあい、エラーもでずに書きこみが終了し、その後、再書き込みも問題なくできました。ライタのLEDは点滅しません。

 つぎに、おなじライタでMCLRをオフにしてプログラム書きこみをしてみました。すると、ベリファイでエラーがでるばあいがあります。その直後から、ライタのLEDが点滅をはじめます。そして、次回からデバイスの消去を実行しても、プログラムの再書き込みができなくなりました。

 では、さいしょに書きこんだプログラムは、PICにちゃんと書きこまれていて、正常にうごいているのでしょうか。実験ボードをつかってテストしてみました。実験ボードは、FENG3がPICの勉強をはじめたころにつくったものです。8つのRBポートにLEDをとりつけてありますので、こんかいPICに書きこんだサンプルプログラムには、うってつけです。さいしょに、MCLRをオンにしてプログラムを書きこんだPICをテストしてみました。ライタに挿入したときにはライタのLEDは点滅しませんでしたが、実験ボードでは、8つのLEDがクロック速度をしだいに遅くしながら点滅します。つまり、ライタのLEDは点滅しませんでしたが、プログラムは正常に書きこまれ、動作していたわけです。MCLRをオンにしてありますので、実験ボードのリセットボタンを押すと、ちゃんとリセットされて、プログラムが最初からスタートします。

 つぎに、MCLRをオフにして書きこんだPICを実験ボードにセットしてためしてみました。こちらも、プログラムどおりに8つのLEDが交互に点滅します。こちらもプログラムは正常に書きこまれ、動作しています。ただし、MCLRをオフにしてあるため、実験ボードのリセットボタンを押してもリセットは効きません。

 それではなぜ、ライタ上では、MCLRをオンにしてPICに書きこんだばあい、ライタのLEDは点滅せず、MCLRをオフにしてPICに書きこむと、ライタのLEDが点滅したのでしょう? こたえは、マイクロチップ社のPIC16F818/819のデータシートに書かれていました。PIC16F818/819では、プログラミングモードに入るさいに、Vddが上昇してから100マイクロ秒以内にVppがプログラミングモードに入るのに必要な高電圧に達している必要があります。そうでないと、IntOSCモードのばあいは、PICが予想外の命令を実行しだすばあいがあるというのです。つまり、PICがライタ上で電源を得てうごきだすばあいがあるというわけです。ですが、MCLRをオンにしたばあいは、ライタにつながっているMCLR端子はLowなので、PICはVddをライタから供給されてもうごきだしませんので、ライタのLEDは点滅しなかったわけです。MCLRをオフにしたばあいはどうなるのでしょう。MCLRをオフにすると、IntOSCモードのばあいは、MCLRがPIC内部でVddにプルアップされるようです。そのために、プログラム書きこみが終了した時点で、ベリファイをまたずにPICがリセットされ、プログラムが実行されてライタのLEDが点滅するようになった、というわけです。

 ところで、おなじJDMプログラマあるいはその改良型で、つかっている部品も回路もそうたいしてかわらないのに、どうしてプログラム再書き込みができたりできなかったりするのでしょうか? これも、実験してみました。実験には、標準のJDMプログラマ、ゼロプレッシャーソケットタイプのPICライタ5号機(以下、PICライタ5号機)、「スマートメディア」サイズのPICライタ(以下、「スマートメディア」…)をつかいました。これらのライタで、さきほどのサンプルプログラムをMCLRをオフにしてプログラムを書きこんで、その後、再書き込みをしてみました。

 結果は、標準のJDMプログラマとPICライタ5号機では、たびたびプログラムの再書き込みができなくなることがわかりました。再書き込みができなくなったばあい、デバイスの消去をなんども実行するか、書きこみソフトIC-Progの「設定」の「ハードウェア」で、「I/Oの遅延」を最大に設定してからデバイスを消去し、設定をもとにもどしてから再書き込みすると、うまくいくこともわかりました。「スマートメディア」…では、問題なくプログラムの再書き込みができました。

 ライタによってなぜちがうのでしょうか? FENG3は測定器具といってもテスターしかもっていませんので、こたえはかんたんではありません。でも、MCLRをオフにしてPICにプログラムを書きこんだそれぞれのライタの端子間電圧を測ってみました。サンプルプログラムは、RB0からRB7の8つのポートに接続されたLEDを点滅させるようになっています。ところが、ライタのほうは、プログラミングに必要な電源と信号ピン以外の「あそんでいる」ピンのあつかいが、それぞれことなります。あそんでいるピンをGNDにおとしているばあいは、VddがGNDにPICのピンをとおしてつながっていることになります。また、LEDを駆動させる電流がライタのクロックやデータラインにまわりこんだりします。そのため、ライタのVddはおおむね、LEDの点滅にしたがって、+5VとGNDの中間値になっていまいます(JDMプログラマのばあいは、1.82Vから2.15V、PICライタ5号機のばあいは、2.15Vから3.0V、「スマートメディア」…のばあいは、2.15Vから2.37Vのあいだをそれぞれ変動)。

 Vppの立ち上がりの速度について、計測してみる必要がありますが、FENG3はその器具をもっていませんので、計測できません。推測になりますが、今回PICに書きこんだサンプルプログラムについては、「スマートメディア」…のVppのたちあがりがまさっていたので、再書き込みが可能になったのではないでしょうか? 他の方の検証を期待します(2003年11月23日 下記の「アダプタの製作です」と前後する内容をふくんでいますが、この場所に追加しました)。

 アダプタの製作です

 16F819でも内部クロックモードでプログラム書き込みをすると、12F629/675と同様の問題がおきるという報告がありましたので、少し前から製作していたJDMプログラマ用のアダプタを公開します。回路図、部品等は上記の追加回路とおなじです。あと必要なものとして、丸ピンの8ピンのICソケットが2個、18ピンのICソケットが1個(これは丸ピンでも平ピンでも可)、ユニバーサル基板のあまり(4×17個の穴が必要です)、線材、接着剤などです。すでにPICライタをこしらえていて、配線が密になっていますと、回路の追加もめんどうなものです。このアダプタは、標準のJDMプログラマやFENG3のホームページで紹介しているPICライタに対応しています。ライタのソケットの8ピンPICを挿入する位置にアダプタをセットして使用します。18ピンタイプのPICでもこのアダプタが役立つのか、検証作業はこれからです。テストされたかたは、結果をFENG3までおしらせくださるとうれしいです(2003年11月16日)。

訂正 18ピンのPICでは、Vddをスイッチさせると読み書きでエラーがまれにでることがわかりましたので、Vddの配線をつけかえました。PIC16F819にどうやって対応するかは、これから模索します。したがって、18ピンのICソケットでなくても8ピンのソケット3個でアダプタがつくれるということになりそのばあいは、基板サイズも4×12の穴数があればいいことになります(2003年11月18日)。

 注意事項:PICライタの製作にあたっては、自己責任でおこなってください。このページに記載されている情報をもとに製作された結果、ライタが動作しない、PICが破損した、パソコンが壊れた、家庭不和になった等の損害を被られても、FENG3はいっさい関知しません。

2003年12月9日追加

2003年11月23日 追加

2003年11月16日訂正と追加

2003年11月8日作成