« 2009年4月12日 - 2009年4月18日 | トップページ | 2009年4月26日 - 2009年5月2日 »

2009年4月19日 - 2009年4月25日の1件の記事

2009年4月21日 (火)

ARM基板にJTAGからのファーム書き込み成功

まっさらな付録基板にはJTAGから書き込めない(4/18/09)
 LPC2388付録基板にUSBソケット、JTAGソケット、ジャンパーピンをとりあえずハンダ付けして、いよいよ実験を開始した。OlimexのTINY-USB-JTAGケーブルのOpenOCDでの認識はDOS画面で認識を確認した。Eclipseに持ち込む。このデバッグコマンドのスクリプト入力が結構大変である。殆ど意味を理解しないまま、フラッシュ書き込みと、デバッグ開始のスクリプトを言われるままウェブ画面からコピーしたりして入力する。A4201806

 zusさんの解説サイトの指定どおり、OpenOCDをEclipseの中で立ち上げる。うむ、ちゃんと正しいメッセージが出ているようだ。次はフラッシュの書き込みである。ここで迷ったのが、CPUモードをISPモードにするジャンパーピン(JP2)の設定である。ファームをJTAGインターフェースからフラッシュに書くのだからISPモードではないと思うが、サイトには何の説明もない。リセットをいつするのかの指定もない。

 わからないときは何も考えずにやることだ。JP2をオープン(通常状態)にし、JP1(リセット)を押した後、フラッシュ書き込みをEclpseから指定した。しかし出てきたメッセージはどうも、ウェブに出ている正常終了のメッセージではない。フラッシュを書き込んだというメッセージが出ない。

出てきたメッセージを訳がわからないまま、一応追っていく。どうも以下のところからおかしい。

cpsr: 0xa00000f3 pc: 0x7fffe152
timeout waiting for SYSCOMP & DBGACK, last DBG_STATUS: 0
Runtime error, file "target/lpc2388.cfg", line 52:
in procedure 'mt_internal_rc' called at file "command.c", line 456

load main.elf
Error erasing flash with vFlashErase packet

メッセージ通り解釈すると、mt_internal_rcというプロセスでRuntime errorが起き、
main.elfというターゲットのバイナリをロードできないと言っている。vFlashErase packetというのがわからないが恐らく消去コマンドの名前だろう。このあと連続するエラーメッセージは、プログラムが書けていないためによるものと思われる。不思議なことにJP2をショート(ISPモード)させてリセットしたあとのISPモードでも同じ結果がでる。

 こうなるとこの先どうしたら良いのかもうわからない。いきなり大量の情報を放り込まれて頭の中は完全に飽和状態である。他のサイトもあたってみるが、思わしい手がかりはない。解説サイトのインストールの手順をその通りやったか詳細に確かめてみるが、どこも間違っていない。完全に暗礁に乗り上げてしまった。

 やれやれ、こうなったら一つ一つ要素を確認していくしかない。まずJTAGインターフェースがOCDのもとで動いていることは別の環境(DOS)で確かめられている。基板はどうだ。仮想シリアルのUSBが動いていることは、PCがCOMポートを認識しているので間違いない。本体のCPUはどうか。そうだ。雑誌の記事には別のライターでプログラムを書き込む手順が出ている。これでCPU周りを確認してみよう。

 早速、FlashMagicという書き込みプログラムをサイトからダウンロードし、雑誌のサイトからテストプログラムのバイナリーを落としてシリアルで書き込むことにした。順調にファームウエアが書き込まれた。リセットしてみる。おお、LEDが点滅を始めた。CPU周りもOKなようだ。 A4201812

 ここで何となく予感がひらめいた。このままもう一度Eclpseを立ち上げてJTAGを動かせばうまく行くのではないかという予感である。何の根拠もないが、昔こんなことがあったような記憶がある。 やるだけやってみよう。 JTAGケーブルをつなぐのももどかしく、Eclipseからフラッシュ書き込みを指示する。おや、出てくるメッセージが違うぞ。うまくいったかどうかはわからないが前とは別のメッセージだ。これは期待が持てる。

 出てきたメッセージを見直す。沢山の経過と警告のメッセージのあと、
wrote 1232 byte from file main.elf in ...... というファームが書き込まれたことを示す行を発見した。やった。やった。うまく書けたようだ。リセットしてみる。見事、LEDが点滅し始めた。思わずガッツポーズが出る。

 勘があたった。最初のシリアルライターのファーム書き込みで何かCPUの状態が変わったのだ。理由はまだ良く分からないが、AVRのフューズビットのようなものがARMにもあってCPUの環境が変わり、書き込みがOKになったような感じだ。Jtagload

 ここ一週間かかりきりになっていたARMの開発環境がやっと所定どおり動き始めたようだ。念のために、こちらのソースに少し手を入れてLEDの点滅間隔を短くし、ビルドし直して書き込む。よーし、JTAGで書き込んだ後は点滅が早くなった。間違いない。新しくファームがJTAGを通して書き込まれている。

 Eclipseのデバッグモードに入る。これも問題ない。ちゃんと指定のところで止まる。レジュームボタンを押すと点滅を再開する。いやあ嬉しい。まだ分からないことだらけだがとにかくARMでの新しい第一歩である。

やっぱりchaNさんのソースを使うのか(4/20/09)
 ARMの勉強を始めて、やっとプログラムの開発が出来る環境が揃った。LEDの点滅はもう良いだろう。次のステップに進もうと、参考になるプログラムソースを求めてウェブをさまよった。 

 このARMはどうもC言語のソースだけでは動かなく、必ずアセンブラーのスタートアップルーチンが必要なようだ。32ビットマシンなので最初の設定が沢山あり大変だ。これはお手本がないと、とてもまともに動かすことは出来ない。クロックすら所定のスピードにするために何段階かの手順を踏む必要がある。

 これからの腹案としては、AVRの時と同じように、UARTを入れてプロセッサーとお話をし、そのあとIICを入れてRTCを動かしたり、LCDをつけたり、最終的には、SDカードアクセスまで進むつもりをしていた。しかしなかなか手頃なソースが見つからない。

 ところが、このあいだダウンロードさせて貰ったchaNさんのLPC2000試食プログラムのソースを少し調べてみて驚いた。これは私が今からやろうとしているアプリケーションをすべて実現した完全なソースリストだ。

 さらによく見てみたら、スタートアップルーチンだと思っていたアセンブラープログラムは、割込みの制御と複数タスクをディスパッチする簡単なマルチタスクモニターであることがわかった。しかもSDカードの中身をダンプしたりするUARTのモニタープログラムまで入っている。うひゃあ、こりゃもうやることがない。

 折角、32ビットプロセッサーなのだからUARTから始めて少しづつ経験値を高めていこうと思ったのだが、ここにみんな解答が出てしまっている。恐れ入りました。WINARMの環境から、Codesourceryに移さなければいけないが、ここは素直にこのソースリストから必要なコードを少しづつ頂いてARMのお勉強をすることにしよう。

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

« 2009年4月12日 - 2009年4月18日 | トップページ | 2009年4月26日 - 2009年5月2日 »