JTAGは気難しい。恐れていた事態が現実になる

　Eclipseの環境が出来て一息入れたのも束の間、がた老AVR研究所は、次々に事件、出来事が発生し、その対応に追われて仕事どころ（あ、いや、一応、まだ週2日程仕事しています）ではない。

BeagleBoardが届いた(5/14/09)
　4/29に発注して、連休中毎日のようにDigiKeyのサイトをチェックしていたが、注文受理から、なかなか発送のステイタスに変わらずイライラしていた。アメリカも連休だったのだろうか。しかし、11日にステイタスが出荷済みになってからは早かった。何と2日で配達されてきた。13日は家人が不在で、今日14日に無事手元に届いた。電話で用途を聞かれたりするそうだが、全くそれらしいことはなし。ハンコを持って受け取りに行ったら、ポータブル端末のスタイラスペンを渡されてサインを求められる。さすが海外便だ。

　受け取ると、中身が入っているのかと疑うほど軽い。初の海外からの通信販売品である。記念写真をとる。充填材の中から可愛い箱が出てきて、いよいよあこがれのBeagleBoardとのご対面。電源アダプターには親切に5Vの表示ラベルが張ってある。モジュラージャックだと思っていたソケットはビデオのS端子だった。え、Sケーブルでも良いの？

　がた老AVR研究所のハイエンドマシンである。このあいだ8 ビットプロセッサーから32ビットにいきなりあがって大変だったが、今度も大飛躍である。CPUチップはARM一族のハイエンドから2番目のARM CortexA8(ARM11の後継）コアとDSP、ビデオコントローラーを内蔵し、RAMがRevBの128MBからRevCでは256MBと増えている。クロックは600Mhzと一昔前のパソコンのスペックに近い。これが7センチ四方のボードに納まっている。

　気をつけなければならないのは、アプリケーションがどんどんパソコンに近づいていくことである。省電力、ファンレスだといくら威張ってみても所詮はローエンドのPCにも負ける。PCと同じような機能を開発してみても始まらない。本当の用途、最終目標が何なのかをよーく考えておかないと何をしているのかわからなくなる。パソコンで出来ることを何を苦労して作っているの？と笑われるのがオチである。

　接続に必要なケーブルで入手が難しいと言われる、USB-Aメス--ミニBオスのケーブルとHDMI--DVI-Dケーブル（これは入手難というより市販品が金メッキなどで異常に高い）は￥680と、￥1300でアマゾンで発注済である。とりあえず動かすのに必要な部品は、シリアルDSUB9ピンコネクターとボードのシリアルピンに接続するケーブルだけとなった。

　具体的なアプリケーションはまだ全く決まっていない。折角AVインタフェースが充実しているので動画関係に使いたいところだが、直接の用途が思いつかない。Linuxを入れてUSB経由のLANとHDDをつけ、とりあえずはディスクサーバーのようなことをやってみようかと思っている。まあ、これも少し先の話だ。DigiKeyでは私が買った数日後、案の定、在庫が0になって売り切れた。ひそかにほくそえんでいたのだが、昨日見たら在庫が25に戻っていた。何だ。次のロットは遅れるなどと言っていたのは誰だ。少々あせりすぎたかもしれない。しかし所有欲だけは十分満たされた。しばらくは棚に飾って喜んでいよう。

やっとフラッシュにJTAGのOCDコマンドでイメージが書き込めた(5/17/09)
　BeagleBoardはさておき、ARMの開発である。次の目標はRTCと決めてあるが、それまでに片付けておきたいことが沢山ある。GDBによるソースコードデバッグは余り深入りするつもりはない。USBやシリアルなどタイムディペンドな機能の開発ではプログラムを途中でブレークすると動作状況が変わってデバッグにならなくなる。恐らくSDカードのアクセスも同じだ。

　ハングアップしたときなどは威力を発揮すると思うが全体がまだわかっていないので使いこなせるかどうか。それにフラッシュ上ではブレークポイントが限られており、自在に止めるにはSRAM上にコードを移す必要がある。しかしSTM32はSRAMが20KBしかないので今のプログラム（既に38KBもある。もっとスリムに出来ると思うがこれも未着手）でも、もう移動不能である。

　で、やろうとしていることはピンを切り替えたり、リセットすることなしに、Eclipseの下でプログラムが書き込め、そのままテストに入れる環境を作ることである。Eclipseにこだわるのは、ここの豊富なソースコードの編集・検索機能だ。表示されているマクロステートメントにカーソルを当てるだけでプロジェクトの中の定義元を調べてマクロを展開してくれるし、外部変数や関数の所在も一発でわかる。沢山のモジュールで構成されるプロダクトではありがたい機能だ。まだ他にも沢山機能があるらしいが調べ切れていない。

ファーム書き込みのスクリプトを作る前に、コマンド入力で、フラッシュ書き込みのテストをする。要は、プロテクトをoffにし、フラッシュを消去し、書き込むと良いはずなのだが、これがこの前に書いたようにとても難渋した。

バンク、セクター、アドレス、オフセットの設定が難しい。まずバンクである。こういうJTAGのような組み込み系ではいくつもあるのが常識なのだろうが、こちらはAll in oneのワンチップコンピューターの世界しか知らない。コマンドにバンク番号を必ず入れるのがなかなか慣れない。

　バンクが常時0なのは良いとして、セクターの数え方が難しい。STM32では消去の単位がセクターではなく独自のサイズを持っており、4セクター単位にきっちりスタートとエンドを入れないと言う事を聞いてくれない。

　アドレスもそうだ。コマンドの指定するスタートアドレスは、0から始まる相対アドレスなのか、実際にメモリマップしたあとの絶対アドレスなのか、コマンドによって違うような気がする。

　flash write_image ファイル名　<offset>　というコマンドのoffsetも良くわからない。ファイルの種類によって違うような気がする。.binファイルなら良いが、elf、hexのような絶対アドレスが内容に指定されているイメージファイルはどうなるんだろう。offsetされるとそれもずれるのだろうか。いや、わからないことだらけである。

困ったときのGoogle頼みだが、的確な情報がない。仕方なく少しづつ実際に確かめて進めるしかない。アドレスを間違えても大丈夫なように、フラッシュの後半のアドレスに狙いをさだめて、コマンドを確かめてみる。

　何度か怒られながら、0xE000のフラッシュエリアに1KB余りのbinファイルを書きこみ、消去するまでの過程を実現するのに成功した。

flash erase_sector  0 46 49                           　セクター4KB単位に消去（必ず4K単位）
flash write_image  XXXX.bin 0x800E000  bin  　  設定アドレスからファイル書き込み
flash  erase_ check  0　　　            　　　　バンク0のフラッシュのerase状態の表示

以上のコマンドの投入で、0x0800E000のセクターがnot erasedになり書き込まれたことが確認できた。このあと、mdw  0x0800E000  256などで、書き込まれた内容を確認する。
さらに、同じflash erase_sectorをかけて再び内容が　0xFFFF…..になっていることを見る。やっとのことで、Eclipseのフラッシュスクリプトを作る目処がたった。

突然JTAGがR/Wエラーでおかしくなる(5/19/09)
　残るは、いよいよEclipseでのフラッシュ消去、書き込みのコマンドスクリプトの作成である。フラッシュを全て消すのでなく、0x3000以降だけを消去するコマンドを作る。OCDのフラッシュコマンドの基本はセクター単位(１KB )で消去の単位は４KBなので、flash erase_sector 0 XX  YYとして、XXを4、YYを127でよいはずである。このあとはアドレスは考慮しなくて良い（はず）。というよりGDBでロードするから、このコマンドはいらない。

　スクリプトにする前に手動でやってみる。ところが、さっきまで動いていたflash erase_sector が言うことを聞いてくれない。何回かやるうちに何とか書き込むべきアドレス0x08003000以降がerasedになったので、flash write_imageでelfファイルを書き込んでみた。ちゃんと書かれたか、flash erase_check 0　で確かめる。

　おやあ、Dfuが書き残してerasedになっていた、0x08002000から3000までのセクターもnot erasedになってしまっている。不吉な予感がよぎる。Eclipseを止めてJTAGをはずし、基板だけで動かす。全く動かない。不安が高まる。動作モードをDfuに変え、再立ち上げ。うわあDfuSeが基板を認識しない。やってしまった。Dfuを上書きしてしまったようだ。

　JTAGを接続しなおし、DOS窓でOpenOCDを立ち上げフラッシュの状況を見ようとした。これがBlock Read Errorのメッセージで見ることすら出来ない。当然、さっき動いたflash write_imageもエラーリターンする。えらい事になってしまった。予想されていた最悪の事態だ。だいたいflash probe 0というフラッシュの全体状況を表示するコマンドも、サイズはわからないけれど、だいたい128Kくらいかなあ、などという頼りない返事が返ってくる。

　こわしてしまったのだろうか。現象はハードエラーのような感じだ。なるべく冷静になって状況を確認する。JTAGはいわばコンピューターの心臓部に直接、検査針をつっこんで制御しているようなところがある。しかし、コマンドで動かしている限り、ハード的に装置をこわしてしまうようなことはないはずだ。ファームに何かを書いたためにCPUが暴走し、JTAGが正しい結果を返せないと考えるのが妥当だろう（そう思いたい）。

　そういえば、前のLPC2388で何もプログラムが入っていない状態では、JTAGでファームに書くことが出来なかった。そうだそれに違いない。気分が少し明るくなった。何か動くプログラムを書き込めば良いはずだ。しかし、Dfuは消えてしまったし、JTAGはこんな状態だ。

　このあいだ「ねむい」さんのコメントを見て、「十分注意しているから、こんな事態にはなるまい」とたかをくくっていた事態が急に現実になり苦笑いである。第三の方法、ROMブートローダーの出番である。この方法があるのは知っていたし、UART1はこの前のGNUサンプルを動かすときに配線済みだが、実際の手順は「ねむい」さんの記事が大変役に立った。「ねむい」さんありがとう。

　手順が決まっていれば後は作業だけである。BOOT0をHighにするピンヘッダーを立て、STマイクロからPC側のダウンローダーを落とし、UART1を秋月のUSB-UARTアダプターとつなぐ。うむ、STM32を認識した。何、フラッシュが全部プロテクトされているぞ。これが原因だったのか。どうせなら、Dfuを復元してやろう。「ねむい」さんのところからDfuのhexファイルを頂きファームに焼きこむ。よーし。USBをつなぐとPCが反応し、DfuSeがSTM32を認識した。

　これでJTAGが動けば、完全に元に戻ったことになる。あせる気持ちを抑えJTAGケーブルを基板に接続し、OpenOCDを立ち上げる。Telnetを開きコマンドを入れる。万歳！これまでのおかしなレスポンスは全くなく正常な状態に戻った。

　やれやれJTAGは気難しい。Block R/Wエラーが頻発しプロテクトの状態がコマンドを入れるたびにおかしな状況になるのは、ターゲットのCPUが暴走していたからに違いない。しかし逆に言うと、CPUを暴走させてしまうとJTAGが動かない状況に簡単になってしまうということだ。これはやっぱり相当経験を積んでからでないと使いこなせないツールのようだ。