OpenOCDでSTM32F4を制御できるらしい
最初にその手の情報をネットで読んだときの感想は「そんな馬鹿な」でした。しかし、この人が言っているなら安易に疑念の声を上げることはできません。
コアのIDはSTM32F2系と全く同一のため、OpenOCDはそのまま読み書き・デバッグを行うことが可能です！ねむいさんはビルドしたプログラムの書き込みにVersaloonのSWDを使用しました。
うむ。探してみると海外でも同じような結果が出ています。
Nabil programed the STM32F4 DISCOVERY development board using the Bus Blaster JTAG debugger and open source OpenOCD software:
つまり、プログラムのロードもステップ実行もできるわけです。
CORTEX-M4コアで何が起きている？
COTEX-M3コア用のデバッガがCORTEX-M4でも動く。これはなぜでしょうか。命令が上位互換だから動いて当たり前、と簡単には言えない事情があります。たとえば、以前私はAsagaoという、JTAGを使ったマイコン用の外付けSPI Flash書き込みソフトを作ったことがあります。このソフトは、コアが同じであってもマイコン毎にJTAGのバウンダリー・レジスタの構成を解析して設定ファイルに書いておく必要がありました。マイコンはダイの設計が同じでないかぎり、JTAGのバウンダリー・レジスタが違います。ですから、STM32F2とSTM32F4は異なるバウンダリ・レジスタを持っており、互換性は無いはずです。
では、何が起きているのでしょうか。
どういうわけか今ARMのInformation Centerに接続できないので詳細はわかりませんが、おそらくCORTEX-M3/M4のデバッグ用のインターフェースはバウンダリ・レジスタを使っていません。私は二社程度のDSPのアーキテクチャしかしりませんが、いずれもコアのデバッグ用レジスタはバウンダリ・レジスタからバイパスされています。こうすることの利点は大きく三つあります。
おそらくですが、バウンダリ・レジスタを使ってソフトウェアのデバッグをするようなマイコンは存在しないのではないでしょうか。結局CORTEX-M3のデバッグ機構とCORTEX-M4のデバッグ機構は同じだろうと推定されます。
だったら、これで万々歳に思えますが、そうは問屋が卸しません。
マイコンのデバッグ機構
JTAGバウンダリ・レジスタではなくJTAG経由で内部マイコンのデバッグを行う一つの方法は、命令デコーダーの入力レジスタにデバッガが実行させたい命令を直接書き込むことです。たとえば、
move debug,R1
と言う命令を置いて1サイクル実行します。すると、R1レジスタの値がdebugレジスタに書き込まれます。このdebugレジスタをJTAGの内部チェーンに配置しておけば、命令を変えることで好きにレジスタの値を読めます。
そんなことをせずにすべてのレジスタにJTAGのレジスタを通せばいい、と考えてしまいますが、そんな事をすると一番速度に影響の大きな回路に重い負担をかけてしまいます。上の方法はめんどくさく見えますが、速度への影響の少ないうまい方法です。
さて、こう説明すれば、CORTEX-M3のデバッガがCORTEX-M4でも動く理由がわかります。CORTEX-M4はCORTEX-M3の上位互換ですから、上のように命令を使ってアクセスできるレジスタならすべてアクセスできることになります。
一方、ディスアセンブルに関してはJTAGにアクセスする層ではなく、上位の層の問題です。ねむいさんの他日のブログでは
ちゃんと浮動小数点命令を使ってくれてますね。標準関数のライブラリはsoft-floatなのでprintf関数などにfloat値を渡す時はいったん汎用レジスタにストアしてます。そして-mfloat-abi=softfp版でもsoft-float版と同じ結果をprintfから吐き出すことに成功しました。
とあり、CORTEX-M4Fに対応していないはずの現行のOpenOCDで浮動小数点命令のディスアセンブルまでできています。これはディスアセンブルをしているのがCodesourcery社のgdbだからです。OpenOCDの仕事は指定されたメモリ領域のデータを読んでいるだけです。これならCORTEX-M3の命令範疇で実行できます。
