SYSLAB blog

Ｃで書くスタートアップのためにいろいろなメーカのスタートアップを探したが中でも STM が気になった。
以前から STM のスタートアップはどれを使ったらよいのか分からないので一々データシートを見るか
MDK-ARM を起動して CPU 型番からスタートアップ名を探していた。
これね
startup_stm32f10x_cl.s
startup_stm32f10x_hd.s
startup_stm32f10x_hd_vl.s
startup_stm32f10x_ld.s
startup_stm32f10x_ld_vl.s
startup_stm32f10x_md.s
startup_stm32f10x_md_vl.s
startup_stm32f10x_xl.s
何とかならないかと思っていたところ、スタートアップの名前が新しくなっていた。
startup_stm32f100xb.s
startup_stm32f100xe.s
startup_stm32f101x6.s
startup_stm32f101xb.s
startup_stm32f101xe.s
startup_stm32f101xg.s
startup_stm32f102x6.s
startup_stm32f102xb.s
startup_stm32f103x6.s
startup_stm32f103xb.s
startup_stm32f103xe.s
startup_stm32f103xg.s
startup_stm32f105xc.s
startup_stm32f107xc.s
種類が増えたが一応名前からスタートアップを選択できる。これは歓迎すべきことだろう。
さて、話はスタートアップのファイル名ではなくてその中身だ。ベクターテーブルを見ていくと
最後に BootRAM が追加されている。確か以前はなかったはずだ。（以前と言ってもずいぶん前だ）
スタートアップにより挿入される位置が異なっている。
0x1CC 0x1E0 0x108 といった具合だ。
また、コードも２種類ある。
0xF108F85F 0xF1E0F85F
調べてみると
F85F F108 ldr.w pc, [pc, #-264]
F85F F1E0 ldr.w pc, [pc, #-480]
ということで所定の位置に挿入されているなら Reset_Handler に飛んでいく機能であるらしい。
そうだとすると startup_stm32f100xb.s と startup_stm32f100xe.s はそれぞれ
0x1CC に 0xF108F85F
0x1E0 に 0xF108F85F
が挿入されるようになるのでこの機能が働かないことになる。
というわけで、もしこの機能を使うなら
startup_stm32f100xb.s の 0x1CC は 0xF1CCF85F
startup_stm32f100xe.s の 0x1E0 は 0xF1E0F85F
でないといけないのではないだろうか？という話なのだった。

私の場合このどうでもいいようなことが気になってしょうがないのだ。
それはそうと、こう種類が増えると IDE のプロジェクトジェネレータをどうしようかということになってくる。
MDK-ARM ならデバイスファイルの CPU 一つ一つにファイル名を書いていくことになる。
Ride7 はどうしよう．．．

そういえば STM の GCC サンプルはいつの間にか Ride7 から TrueSTUDIO に変わってしまった。
もちろんプロジェクトファイルだけの問題なので
使えないと言うわけじゃないんだけど。

追記：
　stm32f4Cube integration with Ride 7 によると Ride7 には Keil *.uvproj project を読み込んで
　コンバートする機能があるらしい。そういうスクリプトがあるならぜひ試してみたい。

参照：
　STMicroelectronics
　AN0063-How to use STM32Cube library with Ride.pdf