ARM STM32基板にSPIインターフェースを作る

トイストーリー3に感動
　家族と久しぶりに映画を見にいってきた。笑わないで！トイストーリー3である。でも、このアニメ映画は、はっきり言って子供向けではない。子供の気持ちを忘れないでいる大人のための映画である。

　電気スタンドがスキップしてくるPIXERフィルムのオープニングを見ているだけで昔CGに夢中になったころの感動で胸が躍るのだけど、この映画は中味が深い。表面の筋を追うだけでは（それだけでも十分面白いが）、作者の本当の意図を理解することは出来ない。

　話はアメリカの典型的な子供たちの玩具（おもちゃ）のたどる運命を、奇想天外なアクション仕立てで辿り、玩具の主人公たちの生きざま（？）の中で、友情の絆の尊さを子供たちに訴えることになっているが、実はこれは表向きの話で、底流には玩具に対する作者の深い愛情が流れている。

　そう、人間は何のために生きるのか。何を糧に生きていくのかを問うている。大学生になって故郷を旅立つ17才の玩具の主人が、主人公たちと別れを惜しむシーンは涙なしには見ていられない。半世紀も前に、古い生家の長い廊下を海に見立て、積み木を組み合わせて戦艦「長門」（大和でなく）を作り、敵空母と海戦をした幼時の記憶がよみがえる。どんな玩具（電子工作の部品も同じ）にも魂と命が宿っている。

久しぶりのAVR開発(7/19/2010)
　それはともかく、FPGAのフォトフレームプロジェクトである。FPGAのSPIインターフェースのコード開発まで進んだ（未テストだが）。次は、プロセッサーにSPIを実装して、いよいよ画像データをFPGAに送る段階である（第6ステップ）。

　当初の予定では、プロセッサーはJPEG画像をビットマップデータにするためにフラッシュが大きくて速度の速いARMを予定していた。しかし、まだ経験が浅いうえにSDカードのファイルシステムが未実装なので時間がかかる。

　早く画像が見たいので手っ取り早いAVRの方でSPIを実装することにした。AVR研究所と名乗りながら、ここ最近はFPGAばかりやっていたが、久しぶりのAVRの開発である。ついでなので、ChaNさんのFatFSのバージョンアップをすることにした。

　このファイルシステムの成長の速度はとても早く、2年前に作ったこのMega128基板のFatFSは、まだTinyFSがあったころの0.04で、去年のリニアPCMプレーヤーが0.07、今はさらに0.08まで上がり、機能が更に充実してきた。

　リリースノートを読ませてもらう。なになに、LFN(日本語ファイル名）が中規模なAVRでも使えるような改修がされている。32KB程度のフラッシュサイズでも動くようだ。素晴らしい。

　このファイルシステムはとても良く出来ていて、プロセッサーの機種に依存しないモジュールと、機種に依存する下部ルーチンが明確に分割されており、沢山のプラットホームで動く。

　バージョンが違っても、上部ルーチンを取り替えるだけで動くと嬉しいが、そこまでは難しいだろう。そのためもありリリースの度に機種毎のサンプルソースがついている。いたれりつくせりの配慮である。

　テストベンチとなるのは、これまで、当ブログに度々登場したMega128の自作基板である。通常は、ChaNさんのFatFSのサンプルソースが入っている。LED電光掲示板や、Xbee電力ロガーの親機にもなった。

　改修にとりかかる。おや、RTC.cが変えられていてエラーが出る。ディレクトリの表示でも変数未定義でコンパイルが止まる。FAT構造体も少し変わっている。やっぱり、全部のモジュールを取り替えた方が無難なようだ。コアサイズもだいぶ大きくなってしまった（25K -> 30K)。まあ、ここのソースは全部入り（コマンドすべてを試せる）なので仕方あるまい。

　SPIのコーディングそのものは、あっと言う間に終わった。早速テストに入る。ロジアナで出力波形を見ると、どうもうまくない。SPIになっていない。送信の合間にクロックが出っ放しになる。これでは同期送信の意味がない。非同期にはスタートビットとストップビットがついているので、1フレームを送ったあと適当に休むことが出来るが、SPIは正確に送信ビット数のクロックで止めないと、あとがめちゃめちゃになる。

　クロックラインのDDRを入力方向にすることで、クロックを止めることができたが、どうやってもストップビットの9ビット目が残る。それに、まれにだが途中でクロックが止まらないところが発生するときがある。ボーレートや、CPUの周波数でも状態が変化する。TXEN（送信開始/停止）も入れるが効果なし。暫くやってみたがあきらめた。

　Mega168(328)の標準USARTでは、この前のリニアPCMプレーヤーで使ったようにSPI（マスターだけ）になることが出来るが、Mega128は古い機種なのでその機能を持っていない。データシートにないことをやろうとするのはそもそも無理なようだ。

Mega128のUSARTでSPIを作るのはあきらめ最終目的のSTM32へ(7/23/2010)
　ブレッドボードでMega168のSPIマシンを作っても良いが、SDカードの配線を組み直すことを考えたら、当初の計画通り、STM32の方で開発してしまう方が早そうだ。SDカードが組み込まれている雑誌付録のCQ-STARM基板、STM32F103VB6基板を取り出した。

　これも1年ぶりのARMである。情けないことにすっかり操作を忘れている。Eclipseの新規プロジェクトすらマニュアルを見ないと作れない。ソースコードは、ねむいさんのFatFSのソースを拝借する。これはMartin Thomas氏がChaNさんのコードを基にSTM32用に公開したものに、「ねむい」さんがSTMのライブラリバージョンを3に上げ、Dfu下でも動くようにしてくれたものだ。

　ディレクトリごとまとめてEclipseのプロジェクトフォルダーに放り込み、refreshをかける。無事、Eclipseのプロジェクトが出来た。makefileとソースの#includeファイルのディレクトリパスを、こちらの環境に合わせコンパイルする。

　おお、エラーも出ずビルドはすんなり終わった。それでは書き込みだ。一番楽な、UARTからプログラムをロードするフラッシュローダーを用意する。この基板はたくさんのブートモードに対応するため、ジャンパーを追加してある。どれがどれだったか、これも全く忘れている。

　おやあ、愛用していたFlashLoaderが動かない（JTAGはセットアップが難しいので先送り）。あちこちいじってみたが、動かない。電源電圧を測るとあれあれ2.5Vしかない。どうも試行錯誤しているときに電源コネクターを逆差ししたらしい。またやったか。しつこいレギュレーターの呪いだ。USBから3.3Vを出すLDOが壊れてしまったようだ。時々しか動かない。

　Digikeyを覗く。ピンコンパチの300mA出力のレギュレーターLDS3985を見つけた。基板に乗っているLD2985のupgrade版らしい。2倍の容量がある。価格も安い(￥101)。これは買うしかないだろう。懸案のXilinx　XCS250E(￥1309)と一緒に発注する。総額は￥7865で、送料無料ラインを余裕で超えた。「ねむい」さんに刺激されてSTM32Fのピンコンパチの新型、STM32F107VC6(￥1369)と、Primer2や、ストロベリーリナックスのSTBee基板の512KBチップSTM32F103VET6(予備のつもり￥1542）がゲタとなった。

　で、CQ-STARMの方だが、LDOが壊れても、3.3Vラインに電源を供給すれば問題ないことに気づき、JTAGのコネクターのVccピンに乾電池をつなぐ。うむ、これまでのRTCソフトのLEDが点滅して無事UARTにも時計表示が出る。本体は大丈夫なようだ。

　しかし、依然としてFlash Loaderが動いたり、止まったり安定しない。電源が低すぎる(3.3Vが3.1V)のか。翌日、3.3VのACアダプターとブレッドボードでしっかりした配線にしてやりなおし。おおお、FlushLoaderが動いたぞ。プログラムのロードも上手くいった。

　やった。AVRで見た馴染みのFatFSのメッセージがARMでよみがえる。flでファイルリストが出た。何と、日本語ファイルも問題なく表示。これはすごい。全く問題なし。感激、感激である。「ねむい」さん、Thomasさん、それにChaNさん、ありがとう。

DigiKeyからチップが届いてXilinx基板は生き返った(7/26/10)
　フォトフレーム計画そっちのけで道草を食っている。DigiKeyは例によって品物が来るのが早い。注文したFPGAチップ、CPUチップなどは、休みをはさんで3日で届いてしまった。本来なら、こわれたSTM32基板のLDO修復から始めるところだが、大物のFPGAをそのままにしておくわけにはいかない。

　XilinxのSpartan3E、XCS250Eチップを厳重な防湿袋から取り出す。いよいよ0.5ミリピッチ100ピンのハンダ付けである。机の周りを片付けて深呼吸し気分を換えて気を落ち着かせる。まずパッドにごく薄くハンダメッキをする。位置あわせを慎重に行って、テープで仮止めし、ルーペで確認する。対角線上の数ピンを軽くハンダ付けし、ずれていないことを確かめてから、フラックスをたっぷりつけ、慎重に各辺をパッドからピンにハンダが吸いあがるようにコテをあてて固定していく。新しいハンダは殆ど使わない。うまく行きそうだ。

　しかし、最後の辺でほんのわずかだが狂いが出ているのを発見する。うーむ、どうしてか。ピンの剛性は余り高くない。ハンダ付けでチップを押している間に少しづつずれてしまったようだ。それならピンをずらせば良いのか。ルーペで見ながら、慎重にずれたピンをピンセットで調整する。何だ、簡単にピンは動く。少しのずれはこれで修正が可能だ。

　機械でハンダ付けしたように均一にはならないが、何とか全部のピンがハンダ付けできたようだ。祈る気持ちで通電。見事、雑誌付録FPGA基板は生き返った。予備があるのでこんどは余裕をもってFPGAをいじれる（おいおい）。　

JTAGでDfuローダーを焼き、Dfu経由でプログラムロードが通った(7/27/10)
　こわれたLDOを新しいLDS3985に取替え、CQ-STARM基板も正常に復帰した。しかし、頼みのFlash Loaderが安定してくれない。あるときは簡単にチップを認識し、ファームロードを何度やっても問題ないのに、一度ご機嫌を損ねると、全くチップを無視する。

「ねむい」さんのブログによれば、最近のSTM32F105、107には、このシステムブートローダーにERRATAがあるようだが、103で不調というのは聞いたことがない。しかも動き方が気持ち悪い。動くときと動かない時の区別がわからない。ROMがこわれている？まさか。UARTの受信側を10KΩで釣って見る方法もだめだった。Falsh Loaderを新しいバージョン（1.3 -> 2.2)にあげたが、こんどは全く認識してくれなくなった。嗚呼。

　ARMのプログラムロードのもうひとつの方法、Dfuは、このあいだフラッシュの頭からサンプルプログラムをFlash Loaderで焼いてしまったので消えている。JTAGは準備が大変だ。しかし、Flash Loaderは動かない、Dfuを消してしまったとなると、あとはJTAG経由しか残っていない。あのややこしいJTAGに頼るしかなくなってしまった。このあいだお世話になったEclipseでの開発環境整備のページを最初から読み直し、いちから出直しである。

　この環境、複雑なこともさることながら、プロジェクト単位に同じようなスクリプトをduplicateして作っていかないと動かないというのが、どうも理解できない。これを回避する方法はあるのだろうが、経験が浅いのでどうやって良いのか分からない。

　しかし、同じ設定をしたはずなのに、今度は、何度やってもうまく書き込めない。すべてエラーで止まってしまう。設定ファイルの海の中で、わけもわからずひたすら泳ぎまわるだけである。本筋と関係ない（プログラムのロード）ところでつまづいている。何を無駄なことをやっているのか自分で自分がいやになる時である。

　ただ救いがある。ツールの一部分、OpenOCDだけは正常に動いており、チップを認識している。結局Eclipseでの動作はあきらめ、DOS画面で、OpenOCDを立ち上げ、TelnetでOpenOCDそのものに手動でコマンドを送ってファームを焼くことにする。いやあ、これも難しい。いくらやってもエラーで叱られる。

　そのうち、いつのまにか、CPU基板のLEDがブリンクし始めた。おや、JTAGでLED点滅ファームが書けたようだ。気を落ち着け、少しづつコマンドを調べて、簡単なファームをbinファイルで書いてみる。よしよし、0x08000000のフラッシュの最初からなら、binファイルで書き込めている。

　これまで動かなかったFatFSは考えてみたら、Dfuのためにオフセットしてある。フラッシュの頭をちゃんとしたDfuローダーにしてやる必要があるのだ。そこで思い出したのが、また「ねむい」さんのDfuローダーV3版だ。

　ありがたくソースを頂く。おお、バイナリまでついている。コンパイルエラーが怖いので、こいつをそのままJTAGで書き込むことにしよう。よーし、書けた。PC側のDfuSeもバージョンアップする。やったやった、USBをつなぐとPCが反応し、DfuSeにターゲットチップの型番が出た。

　とりあえず、STM32の書き込み手段のうち、2つまで復活した。この3日間ほとんどこれにかかりきりだった。Dfuseを通して、最初のFatFSプログラムを送り込み、動作を確認した。やれやれ、やっと元の道に戻ってこれた。それにしてもこのところ「ねむい」さんのブログにはお世話になりっぱなしである。ありがとうございました。