« 2011年12月 | トップページ | 2012年2月 »

2012年1月の2件の記事

2012年1月15日 (日)

STM32基板が動かなくなった意外な原因とは

 前記事から2週間近く経ったが、電子工作の進捗ははかばかしくない。今年も新年早々からまたお馬鹿な失敗をご紹介することになった。なぜか当研究所の電子工作は、いつも、はらはらどきどきのドラマの連続である。

次のプロジェクトはグラフィック気圧計か(1/4/2012)
 お正月が明け、Dragonのデバッガーもとりあえず順調に動いて一段落である。今すぐやらなければならない工作は当面なくなった。次のプロジェクトだが、これが、何にしようか迷っている。O-Familyさんと、すんさんが始めた気圧センサー(MPL115A2)の実装をそろそろ始めようと思っているが、いまひとつ意欲が高まらない。

 どうせ、作るなら単なる後追いではなく、何か少し面白いしかけを加えようと欲張っているので、具体的な計画がなかなか考え付かない。そのなかで思いついたのが、大分前にAitendoから買った2インチTFT液晶モジュールと、STM32用の生基板を活用するアイデアである。

 この2つの基板は、確かガイガーカウンターの高圧用部品を買うときの送料コスト低減のため特にあてもなく買った基板で、具体的な目的がないのでそのままになっている。2インチTFT液晶モジュールは、去年のトラ技誌2月号で記事になったYHY024006Aである。 一方のSTM32基板は、部品の載っていないプリントだけのCPUボードで、CPUは、100ピンのSTM32F103用である(¥450)。

S_p1154588 すんさんが、このあいだグラフィックLCDで気圧の遷移をグラフに表示した気圧計を掲示板で発表されたのを見ているうち、この液晶を使うことを思いついた。気圧のグラフは更新単位がほとんど時間レベルなのでTFTのドライブは8ビットのAVRでも十分だが、ここはSTM32基板を一緒に使おうと思う。

Ws000000_2 今やSTマイクロのARMプロセッサーは、STM32F4XXシリーズの時代になってしまっているが、実は当研究所にはSTM32F103とSTM32F107の2つのCPUチップの在庫がある。

 2年前、FPGAでフォトフレームを作ったとき、JPEGのデコードでSRAMが足らないので、雑誌付録基板(CQ-STARM)のCPUをSRAMが64KBあるSTM32F103-VE6に換装し、ついでにその頃は新製品のSTM32F107をDigiKeyで買った(¥1365)。DigiKeyの送料のゲタに使ったので具体的な用途は決まっていない。Aitendoで生基板を手に入れたのは、これを実装しようと考えてのことである。

 この石は、LPC2388と同じようにEtherNetの論理層(TCP/IP層)や、I2S(デジタルオーディオインタフェース)を持っているし、フラッシュ256KB、SRAMも64KBある。がた老AVR研究所ではまだまだ旗艦クラスの立派な32ビットプロセッサーである。

 気圧センサーMPL115A2を動かすだけには、少々役不足(もったいないという意味)だが、在庫整理ということでは申し分がない。すんさんが実現させてしまっているが、気圧の変化をグラフにすれば人間も天気予報に参加できる。カラー表示が出来るし、ネットワークで飛ばすことも出来る。先の長い話だが、これをプラットホームに進めていこうと考えた。

 STM32基板の方はこの基板で使っている表面実装の3端子レギュレーター(AMS1117 ¥100)をAitendoで見つけて、半田付けしたり、チップコンデンサーをつけたりして少しづつ実装を進めてきた。手を動かしていないと落ち着かない性分になってしまっている。これが結構、楽しい。ただ、このSTM32基板はXtalを除いた部品がすべて表面実装品で、そう簡単には部品は揃わない。

100ピンLQFPのハンダ付けで冷や汗(1/5/2012)
 チップ抵抗などの表面実装部品は、以前、千石で買ったジャンクのギターアンプ基板から採集し、コレクションの蝶よろしく紙に貼り付けてあった。パルストランスをはずしたNIC基板からも、このあいだ採集した。こういう作業は、やり始めると止まらなくなる性質がある。かれこれ30ヶ以上のチップ部品が集まってきた。

P1154586 基板の配線図をショップのウェブから入手し、部品リストを作る。そろそろCPUチップをこの基板につける機運が高まってきた。何度目かの0.5ミリピッチ、100ピンLQFPのハンダ付けである。もう何度もやって成功しているので、気楽にとりかかった。

 厳重なDigiKeyの防湿袋から秘蔵のSTM32F107を取り出し、位置を何度も確認しながら、ハンダ付けに入る。フラックスをたっぷりつけると位置が固定し易くなる(フラックスが粘ってくる)。順調にハンダ付けが出来たので、ルーペでチェックする。おやあ、角の1ピンがもともと歪んでいて歪んだままハンダがついてしまった。ついてはいるようだが、見栄えが悪い。修正に入る。

 ところが、ハンダごてで、ハンダを溶かしながらピンセットでピンを元へ戻そうとしたらパタンが基板からはがれて宙ぶらりんになり真っ青になった。ルーペで慎重にパタンを戻し、ピンを元へ戻して、慎重にハンダを盛る。ああ、何とかつながった。

 いやあ、油断するとろくなことがない。それにしても¥3000も出せば、CPUチップのついた完成品のCPUボードが簡単に手に入る時代である。この基板が¥450。チップのSTM32F107は¥1365。¥2000近くかけて、生産性から言えばこんな苦労までするのは割が合わない。

 それはその通りだけれど、完成したCPU基板を使うだけでは何となく面白くない。人と同じことをするのが嫌いな「へそ曲がり」である。表面実装部品の取り付けには格好の練習にもなると自分に言い聞かせる(まあ、ケチなだけだけど)。

1608LEDのハンダ付け練習(1/6/2012)
 部品リストと、採集した部品をチェックしてみると、殆ど買いに行かずに基板が完成しそうである。多量に使う10KΩのチップ抵抗などは足らないと思っていたが、NIC基板に沢山あるのが見つかり、足らないのは、RTC用の32.767khz水晶のコンデンサー(10PF)くらいのものになった。これは今すぐ必要がない。買い物に行かずに基板の動作テストまで出来そうだ。

 パターンが出来ている時の表面実装部品のハンダ付けは、DIP部品などよりはるかに早い。次々にハンダ付けが進み、LEDの部分が出てきた。よーし、これまで買ってあって使う機会のなかった1608サイズのLEDをつけるチャンスである。

1608led_

 これまで買ったLEDの最小部品である。ピンセットで恐る恐る取り出す。これは小さい。ちょっとみたところでは、どちらがアノードなのかわからない。印がないのだ。ルーペで見ると電極が見える。電極が半導体に刺さっている方がアノードらしい。

 つけてから修正するのは面倒なので、実際の小さな基板の切れ端にLEDをつけて試してみる。ハンダ付けの練習を兼ねている。いや、1608クラスのチップを汎用基板にハンダ付けするのは大変だ。

S_p1154585

 ブレッドボードに差してテスト。めでたく点灯した。いやいやこんな工作でも明かりがつくと楽しい。しばらくこれまでに作った各色のLEDテスト端子をつけて遊ぶ。

CPU基板のブートローダーが動いた!(1/8/2012)

 お正月休みの間に、少しづつハンダ付けを続けて、今夜半、殆どの部品を遂につけ終えた。結局すべて在庫のパーツで間に合った。JTAGのところの抵抗がひとつ足らないが、JTAGを動かさなければ問題ない。

S_p1084574

 こういうときの通電はいつも緊張し、中々決断がつかないのだが、思い切ってUSBケーブルを挿して通電する。電源をUSBバスから貰う接続にしてある。よーし、緑のLEDが点灯した。CPUチップは全くの新品である。BOOTモードをシステムメモリから立ち上がるようにして、ねむいさんに教わった例の中華製シリアルプログラムライター、MCUISP.exeで動作を確かめる。

 システムブートで内蔵のブートプログラムが動くはずである。しかし、全く反応がない。タイムアウトでライターが接続をあきらめた。試しに、オシロでクロックを確かめるが、全く出ていない。ありゃあー、これじゃあ駄目だよね。

 いや、待てよ、これはこのままで良いはずだ。STM32あたりになると、内蔵のCRクロックでまず動き、あとはインストラクション(命令)で主クロックを起動させるはずだ。

 動かないのはハードが原因だ。いや、プリント基板なのでハンダ付け不良が最も疑われる。ルーペでCPUチップまわりを仔細にチェックするが、問題になるようなところは見つけられなかった。

 そのうち、BOOTモードを決めるピン配置が気になった。どうもプルアップをスイッチでショートするような回路になっていない。配線図と実際の結線を確かめる。やはりそうだ。ピンから抵抗をとおして、Vccか、GNDにつながるようになっている。つまりプルアップかプルダウンをするような設定だ。となると今のショートピンの設定は0と1が逆だ。

Stm32f107_start

 設定をちょうど逆にする。MCUISP.exeのread chipボタンを押した。やった。CPUを認めた。256KBのフラッシュ、64KBのSRAMの表示。やれやれ、とりあえずハンダ付けはすべてうまくいったようだ。これで表面実装のハンダ付けにも少し自信がついた。

Flushloader

 このあと、STマイクロの提供するFlushLoaderでも動くことを確認した。以前はあんなに気難しかったローダーが、STM32F107ではすんなりチップを認めた。この基板にはまともなシリアル変換チップ(ADM3202)が載っているからかもしれない。

突然動かなくなる(1/11/2012)
 どうしたことだ。STM32基板は、JTAGコネクターまわりや、RTCの発振子のコンデンサーなどの残りのパーツを付け終わって、2日ぶりに動作させてみたら動かなくなった。MCUISPがチップを認めない。勿論FlushLoaderも拒絶する。

 追加した部品は、そもそもブートローダーの動きに関係ないと思われる部品ばかりである。もしあるとするなら、JTAGのリセットピンに関係する抵抗で、店のサイトから落とした回路図には、"don't at"という奇妙な注釈があって、NRST(システムリセット?)と、NJTRST(JTAGのリセット?)の間をつなぐ230Ωである。

 回路的には、システムリセットをしたときに、JTAG側もリセットしようという意図で付けたと見られる抵抗だが、この注釈が意味不明である。つけるなという意味にも取れる。ただ、この注釈は隣の定数が書いていない抵抗のことかも知れないので何とも言えない。

 そもそも、JTAGコネクターには何もつながっていないので、問題になるわけがないが、新しい要素はこれくらいしかないので、ハンダごてを出してはずしてみる。勿論、事態は変わらない。

 他に関係のありそうなところはない。RTCの発振子のドライブコンデンサー(10PF)をつけたが、これでおかしくなることなど普通あり得ない。念のため、Vbatへの0オームをはずして、Vbatの電源供給を止める。もちろん変わらない。

 あとはJTAGのソケットをつけただけだ。これで動かなくなる。そんな、信じられない。さすがにこの取り外しは止めた。しかし、ブートローダーが動かない限り、今のところ何も先に進めない。頭を抱えてしまう。

やっぱりCPUが壊れているのか(1/12/2012)
 新年早々、久しぶりに暗い気分に落ち込む。世の中すべてが自分に敵対しているような感じになる。家人との応対も上の空である。大したことでもないことにめげて、そういう自分が嫌でまたさらに落ち込むという負のスパイラルに陥っている。

 実装して一旦動いたSTM32基板が突然動かなくなったのだ。思い当たるところがない。これまでの調べでは、CPUへの電源供給は異常なし(10mA程度)。各部の電圧も規定どおり。シリアルの送信も間違いなくCPUのシリアルピンに届いている(オシロで確かめた)。しかしレスポンスがない。

 STM32は、ブート時は内蔵クロックで動くので、CPUが正常に動作しているかどうかを外部から知ることが出来ない。ところが、オシロで各部の電圧をチェックしているうち、異常な部分を見つけた。リセットピンにパルスが出ている。リセットすると一旦グランドに落ちるが、プルアップの状態で、400Hzくらいの矩形波のパルスが出ている。電圧は電源電圧の半分程度。

 そんな馬鹿な。リセットピンは入力ピンで、こんなパルスが出るわけがない。試しにプルアップ抵抗をはずしてみた。同じようにパルスが出る。リセットスイッチに並列に入っているコンデンサーもはずす。きれいな矩形波になっただけで変わらない。10kではなく、1kでプルアップしてみるも効果なし。Vcc直結はさすがにやめた。

 これはCPUの内部からの電圧だ。そう思いたくはないが、これは、やっぱりCPUのどこかが壊れた公算が強い。そうでなければリセットピンに電圧変化が出るわけがない。しかし、どうして壊れたのだろう。静電気だろうか。オシロのプローブなどをあてたこともなく、ショートさせるような作業はやっていない。

 CPUチップの替えは、あることはある。このあいだのCQ-STARM基板のCPU換装の時にはずしたオリジナルのSTM32F103だ。しかし、原因不明で動かなくなったというのが悩ましい。これをつけてまた壊してしまうかもしれない。原因がわかるまで下手なことは出来ない。

 しかし、このままでは工作が続けられない。思い切って取り替えてみるか。まだ決断がつかない。まわりをうろうろするばかりである。たかだか¥1000ばかりの石であるが、値段というより0.5ミリピッチの100ピンのQFPのハンダ付けの作業ロードを考えると気が重い。

益々混迷を深める(1/13/2012)
 暫く迷ったが、意を決してCPUを交換することにした。苦労してつけたSTM32F107を低温ハンダをたっぷりつけて取り外す。壊れたとは限らないので、ハンダ吸い取り線で丁寧にピンからハンダを取り除く。低温ハンダは、このあいだ買ったストロベリーリナックスのものである。サンハヤトの1/3の価格(一時、品切れだったが、最近戻ったようだ)で、効果は変わらない。

Chipwick

 しまってあった雑誌付録のオリジナルCPU、STM32F103をとりだしハンダ付けに入る。こういうこともあろうかと、チップを綺麗に掃除してあったので助かった。順調につけられた。

 配線パタンは、前に、無理に付けようとして1ピンのパタンをはがしている。そこも何とかハンダを盛って接続する。気がせくが、ここであせって失敗しては元も子もない。慎重にテスターで確かめる。よし大丈夫だ。ルーペでハンダブリッジがないかもう一度良く確かめて、通電する。

 さあ、どうだ。シリアルローダーの反応はない。動く気配はない。しかも何ということだ。依然としてリセットピンに矩形波が上がっている。苦労してCPUチップを取り替えても同じ現象である。

 これはCPUチップが悪いのではない。別のチップで同じ現象が生まれることはあり得ない。基板がおかしいのだ。やれやれ、100ピンのハンダ付けが無駄になった。まあ、STM32F107が生きていただけでも救いなのだが、原因がわからないことに変りはない。

フェライトチップビーズのハンダ付けが原因とは(1/14/2012)
 この3日間、悩まされてきた問題は、あっけない原因で解決した。真の原因は未解明だが、AitendoのSTM32基板は、正常な前の状態に戻った。しかし未だに信じられない。ハンダ付け不良が、リセットピンの発振を招くとは。いやそれにしても恐ろしい話である。

 最初はシステム内蔵のブートローダーが動いていたのに、残っていた部品をつけたら動かなくなった。リセット電位を測ると、400Hzくらいで発振している。Vccは3.3Vで安定している。消費電流も10mA以下で問題ないが、リセットピンがこんなに上下していたら動くわけがない。

 追加した部品はすべて基本的な動作に関係がありそうなものはない。それでもJTAG関係は微妙なので、ひとつひとつ部品をはずして調べたが、全く事態は変わらなかった。CPUを疑って、昨日、意を決して交換したが、これでも事態は前と変わらない。がっかりすると同時に少し安心する。STM32F107が壊れていたわけではないのだ。

 さあ、こうなると基板のどこかが悪いということになる。全く関係ないと思われるRTCのコンデンサーをはずす。これもだめ。次はJTAGの20ピンのソケットだ。こんなわけはないが、動いたところまで現状を戻していくしかない。多ピンのソケットの取り外しは厄介だ。低温ハンダの助けを借りる。結構手間取って外した。テストする。当然のように事態は変わらない。

 もう、やるところがなくなった。基板を上を何度もチェックする。これ以外にいじったところはない。しかし何気なく基板を裏返して気がついた。そういえば裏には、アナログ系に電源を供給するフィルターのフェライトビーズがついており、これを手持ちの大きなチップから、この間秋月で見つけて買ってきた2012の小さなチップに取り替えた。

 こんなものが変化をもたらすとは考えられない。しかし、もうこれしか動いた時からいじった部品は、基板上のどこにもない。これだけが残っている。しかし、この部品はこのあいだ導通をテスターで確かめて問題ないことを確認している。これが原因とはとても思えない。

 やってもしようがないとは思うが、残っているのはこれしかない。ハンダごての電気を入れて、前のものに取り替えようとした。すると、片側のパッドにハンダごてをあてた途端、チップがポロリとはずれた。うっ、これはおかしいぞ、ちゃんとハンダ付けされていなかった?

 うーむ、何か匂う。もしかしたらもしかするかもしれない。念のため、前のフェライトビーズにとりかえて、シリアルケーブルをつないでブートローダーのテストをした。うわお、これだ。シリアルプログラマーMCUISPにレスポンスが返ってきた。

 STM32基板は前の状態に復帰した。何だ何だ。これは一体どうしたことだ。リセットピンは問題なくVccに上がったままになった。MCUISPの画面には、STM32F103の情報がしっかり表示され、基板は生き返った。

 こんなことってあるんだ。フェライトビーズが悪かったのか。いや、フェライトビーズを前の2012のものに取り替えて、しっかりハンダ付けすると、このチップでも問題なく動いた。フェライトビーズが悪かったからではない。早い話がハンダ付け不良である。

 恐らく、ハンダが微妙な半導通状態で、ここがコンデンサーかダイオードの状態になってアナログ基準電圧が不安定な状態になり、リセット系に悪さをしていたと考えられるが、正確なことはわからない。いずれにしても、基板は、CPUチップを認識する状態に戻った。やれやれ3日間は完全にこれにふりまわされた。

 このあと、正規に動かそうとするが、中々動かないことは次回に紹介するとして、とりあえずこのあたりで報告しておこう。このあいだ、「七転八倒、四苦八苦」とコメントされて、ちょっとむきになっていたけれど、いやいやそんな偉そうなことは言えません。その通りです。はい。

| | コメント (3) | トラックバック (0)

2012年1月 3日 (火)

AVR Dragonのデバッガー機能 debugWIREにはまる

みなさまあけましておめでとうございます。

 がた老AVR研究所は、ブログ公開以来、4回目の新年を迎えました。

 始めは備忘録のつもりで、気ままな電子工作の記録を残そうと始めたのですが、根が凝り性なもので興味に任せて色々手を出すうち、どんどん店が拡がり、昨年はガイガーカウンターを2台も作ってしまうほどのはまりようです。

 いつのまにか電子工作と、このブログが、すっかり生活の一部になり、おかげさまで昨年末には遂にブログの累計アクセスが40万件を越えました。応援していただく人も増えて、いつも沢山コメントを頂戴し、何やら自分勝手なことができない雰囲気です。

 あ、これは困ったと言っているのではありません。昨年は世界中で大きな天災が続いて、人と人の絆がこれほど強く意識された年はありませんでした。その点で、本来、孤独な趣味である電子工作をむしろ、こうしてみなとつながって続けられることは本当に得がたいことだと感謝する気持ちで一杯です。

 そういうことでもありませんが、新年初ブログのお題は辰年にふさわしく、要望のあったAtmelの純正プログラマーAVR Dragon(龍、辰)のデバッガー使用報告です(2012年1月3日記)。

P1034563今年(2011年)の暮は猛烈に忙しかった(12/25/2011)  それにしても、今年は11月末あたりから行事の連続でめちゃめちゃ忙しかった。50年ぶりの小学校の同窓会から始まり、年末の法事まで1ヶ月の間に2回も関西を往復した。忘年会は全部で6回。これに恒例のフルートの発表会や、テニスの納会、属している団体の研究会の幹事、さらに人間ドック、よせば良いのに、パソコン用の地デジのチューナーを買ったりしてそのセットアップ。ジャンクのHDDを買ってPCの環境整備(160GBが¥400という安さで思わず購入。Cディスクを取り替えた)などなど。のんびり半田付けをやっている時間がほとんどなかった。

 それでも、暇を見つけては、このあいだ完成した熱電対で温度制御するアクリル曲げ器を実際に使ってみたり、細かい電子工作はやっていた。アクリル曲げ器は少し厚いアクリルの小片などを使って、テストしている。230℃くらいで表面が150℃になる(放射温度計で測定)。温度が安定しているので工作しやすい。

 このあたりの温度で、アクリルを曲げる線に合わせてパイプに当てていると、うまい具合に焦げずにパイプにあてた直線部が柔らかくなってくる。適当なところでパイプから離し、手で曲げると実に簡単に曲がる。

S_p1034551 練習用のアクリル端片をコの字型に曲げただけだがけっこう綺麗に曲がった。ただ、正確に曲げるには何か治具に当てて曲げる必要があるかもしれない。暫く練習を続けて、ゆくゆくはケースを自作しようと思う。

Dragonのデバッガーに手軽に手を出してはねつけられる(12/28/2011)
 そうこうするうち、前から欲しかったAtmel純正パラレルプログラマーDragonがDigiKeyから届き、その使用記をブログに載せたら、思わぬ反響があった。Dragonを買った目的は、フューズビットを書き損なったチップをパラレルプログラミングで救済するのが主で、デバッガーについては正直なところ殆ど考えていなかったのだが、複数の方からDragonのもうひとつの機能、デバッガー(debugWIRE)のテストをお願いされてしまったのである。

 所長は、前から記事やコメントに書いている通り、デバッガーは余り使ったことがない。大型汎用機の出身なので、そもそもデバッガーに縁が薄かったということもある。ICEや、デバッガーは本来、UNIXやPC、組み込み系コンピューターなど、比較的規模の小さいCPUを対象とするツールで、汎用機ではCPUを止めてデバッグすることなど思いもよらず、オンラインシステムのデバッグの武器はコア(メモリー)ダンプリストとトレースが主であった。

 何度も言うように、ペリフェラル(周辺機器)を含めた実機のデバッグ(オンチップデバッグ)は、タイムアウトでペリフェラルが止まってしまわないような周到な準備が必要だ。しかしバグは大抵こうしたペリフェラルとのやりとりのタイミングにひそんでいることが多く、ここを別の仕掛けで補っても、実際の実機での不具合をつきとめることは難しい。

 単にロジックの部分でCPUを止めてみても、あまり意味がない。変数を見たければprintfをはさむだけで十分用は足りる。当研究所のシステムには本番でUARTを使わないものでも必ずUARTを内蔵しているのは、いつでも内部の変数や、動きが外に見えるようにするためである。UARTが遅くて系に影響を与えるなら、空いているポートを叩いて、そのピンをロジアナで見ればよい。

 そんなわけで、オンチップデバッガーの機能を動かすことには余り気が進まなかった。しかし、ウェブを見ていると、このDragonは、極めて廉価で実機によるソースデバッグができる優れものなのだそうだ。ウェブサイトには、このデバッグの様子を動画で公開しているところもある。一度は経験しておかないとやはりまずい気がしてきた。

S_pc284516 で、パラレルモードでなく、ISPモード(debugWIREモードを兼ねる)のジャンパーを作り始めた。パラレルの20本近くのジャンパーではなく、こんどはたかだか6本の配線である。あっというまに出来あがった。起動も簡単である。AVRStudioを立ち上げて、DEBUGメニューからstart debuggingを選ぶだけである。

 途中、debugWIREモードにISPを通して入るかというダイアログが出て、そのラジオボタンを押すと、プログラムがロードされデバッガーが簡単に動き始めた。ちゃんとCのソースコード画面にブレークポイントの矢印が出て、プログラムの最初のところで止まる。ステップ動作を指定すると、ひとつづつ実行し、サブルーチンに行けば、そのソースリストの画面に替って矢印が移動する。おお、中々やるじゃないか。

Dragon1

 しかし、動かないシステムのステップ動作は、わくわくするが、動いているシステムの動きを見ていても正直あまり感動はない。それに案の定、ピン割り込みのループで待つところで延々とループを始め、先に進まなくなった。CPUはDragonのプロトタイプ基板で動かしているので、ピンは裸だ。先に進みようがない。

 まあこんなものかと思ってとりあえずstop debuggingを選んでデバッガーを止める。ところが、次からガンとして言うことを聞かなくなった。CPUを認めないのである。編集/プログラム画面は出るが、start debuggingを選んでも、デバッガーモードにも戻らない。

 ええー、どうしてだ。メッセージは「ISPモードでない」と言っている。なにー、デバッガーモードから戻る時に、フューズビットをリセットしないのか。パラレルモードでないと変更できないと言っている。これは不便だ。パラレルモードと、ISPモードでは配線が違う。デバッグに入るたびに、ジャンパーの配線換えをしなければならないのではたまらない。

Dragon2

 何か手順があるはずだ。こういうことになると、すぐに意地になるというのがいつものパターンである。自慢にもならないが「へそ曲がり」の性格なら誰にも負けない。こいつをちゃんと動かせるようになるまで、他の事にかかわれなくなってしまった。

やっとdebugWIREを動かせるようになった(12/31/2011)
 Dragonは当初考えていた以上に、多彩な機能をそなえている。まず、ファームの書き込みやフューズビットの書き換えなど、プログラマーの機能としては、ISP、パラレル、HVSP、JTAGとなんと4種類ものインターフェースで動く(ジャンパーの接続と、IDE(AVRStudio)で選択)。

 さらに、オンチップデバッガーは、JTAGとAtmel独自のプロトコル、debugWIREでソースコードレベルのデバッグが出来る(デバッガーソフトはAVRStudioで、チップによりJTAGが使える)。

 ところが、前にも書いたように、このあたりの実際の操作法は、マニュアルに余り詳しく出ていない。日本語のマニュアルはあるが、この翻訳がデータシートに較べると、あまり上手でなく意味がとりにくい(PDI物性などと書かれると意味不明。PDI physicalなのだが、これはPDIハードとでも訳すべき)。原文にもあたるがJTAG周辺の専門用語に馴染みが薄いので、どうもよく理解できない。

 現在のトラブルを整理してみる。要するに、デバッガーモード(1wireデバッグ、debugWIREモード)から、単に、stop debuggingで抜けると、フューズビットのDWENが元へ戻らず、そのチップはISPモードでなくなり、しかもstart debuggingでデバッガーモードにも戻れない。

 こうなると、ファームの書き込みまでできなくなってしまい、パラレルプログラミングでフューズビットを換えないと元に戻れない。これでは連続したデバッグに大きな支障がでてしまう。

 いくつかのウェブサイトの実行報告も、このあたりは、いまひとつはっきりしない。みんなどうしているのだろう。あれこれ、AVRStudioの中を探し回る。その結果、やっとマニュアルの中で手順を発見した。「デバッグWIREインターフェースを通した目的対象への接続」の一番下の記事に、「ISPインターフェースの再許可」というところである。DEBUGメニューの中の「AVR Dragon Options」を開き、そのなかの、disable DebugWIREボタンをクリックしろとある。

 やってみた。ちゃんと出来た。ダイアログに答えていくとISPモードに戻った。マニュアルを読まないのが悪いと言われればそれまでだが、タイトルが「ISPインターフェースの再許可」では初めての人にはわからない。それにソフトの設計としてはこれはまずいだろう。stop debuggingのときに、ダイアログを出して聞けばすむ話だ。不親切なことおびただしいと八つ当たりする。

 そのうえ、このオプションを操作せずにうっかりstop debuggingしてしまったチップは、この方法をとれない。デバッガーモードに戻れず、このメニューが有効にならないからだ。パラレルプログラムで、DWENフューズビットをいじらないと元へ戻らない。

 なおも、しつこく探し回る。そして遂にISPモードの結線のまま、DWENフューズをリセットする手順を見つけた。その方法とは、コンパイルのとき、BUILDではなく、BUILD&RUNを選ぶのだ(ボタンはBUILDの右どなり)。こうすると、コンパイルをしたあと自動的にデバッガーモードになるので、DEBUGメニューの「AVR Dragon Options」が有効になる。ここでdebugWIREモードをキャンセルしてISPモードに戻れば良い。

 いやあ、気分が良い。これで面倒な配線換えをしないでも気楽にデバッグと編集/プログラムの画面を行き来できる。このあたりをわかりやすくするため、図を用意した。青い矢印で書いたところが、所長が発見した手順、赤がマニュアルに出ている復帰手順である。本来は3段目のステートに行かないようにしておくべきだろう。

Dragon_statemap

 気難しいDragonを飼いならして、ようやくデバッガーが快適に操作できるようになった。手が空いたのでTiny2313とTiny861専用のパラレルプログラミングのジャンパーをフラットケーブルから作る。これで、少々フューズを書き損なっても安心だ。これまでメモで書き散らしていたブログの原稿を整理し、新年のために工作室を片付ける。そうこうするあいだに、2011年はとうとう大晦日を迎えてしまった。

| | コメント (7) | トラックバック (0)

« 2011年12月 | トップページ | 2012年2月 »