[ble][nrf51]開発環境アップデート(そして失敗)

環境を作ったばかりだったが、nRF51の新しい環境が出てきたので、今のうちにアップデートしておこう。
アップデートのペースを確認してないんだけど、頻繁じゃなかったら良いなあ。

---

まず、nRF51 SDKがv6.0.0になった。
これは、S110 v7.0.0になってるとのこと。
うん、確かにincludeフォルダが一致していた。
しかし、includeフォルダ(SDK展開後だとinclude/s110)だけ見ても、S110のどのバージョンかわからないのよねぇ。
どこ見たらいいんだろう？

細かいけど、SVDフォルダに入っているxmlファイルも微妙に変わっていた。

---

次は、うちの環境に合わせる。

まず、ARM-gccのパス設定。

C:\Nordic Semiconductor\nRF51 SDK_v5.2.0.39364_Backup\Nordic\nrf51822\Source\templates\gcc
Makefile.windows

サンプルの、nrf51822/Board/nrf6310/s110/ble_app_hrs/main.cを書き換えて、内部32Kクロックに変更。

今回からMakefileにいくつか種類があるようなので、どれかをコピー＆リネームしてMakefileにする。
C:\Nordic Semiconductor\nRF51 SDK_v6.0.0.43681\Nordic\nrf51822\Board\nrf6310\s110\ble_app_hrs\gcc

そして、ビルド。
デバッグ設定はoutファイルのパスが変わっているので(以前のhrsデバッグ設定が残っていれば)、変更しておこう。

---

nRFgo StudioでS110 v7.0.0を焼く。
こうなった。
Enable SoftDevice protectionって、チェック外したけどよいのかな？

あれ、Unknownって出てるぞ？？

Enableうんぬんをチェックしてなかったせいか？

Regionが0になったけど、それだけ。
Verifyしたけど成功するし。
うーん・・・。

こう思うことにした。
私がインストールしているnRFgo Studioは、まだファームウェアIDが0x004Dまでしか対応してないんだ。
v6.0.0は0x004Dだったからファームウェア名も表示できたんだけど、v7.0.0は0x004Fになってて、対応する文字列がないからUnknownになってるんだ。

---

S110 v7.0.0になってからSoftDeviceのサイズが大きくなり、それによりリンクするアドレスも変わってくる。
これは、gccのtemplateを使っている場合は、v7.0.0用に差し替わっているようだ。

だから、このままビルドしてデバッグ実行すれば動く！・・・
動かない。

main関数にすら止まってくれない！
何か失敗した？？

でも・・・デバッガをはずして、BVMCN5102にだけ電源を供給すると、無線が出てる。
焼けてはいるってことかい？

 

１つ気になっているのは、Makefile.commonが変更になっていて、allの動作が「clean debug」から「clean release」になっていること。
でも、eclipseのデバッグ設定で、ConfigurationはDebugにしてるんだけどな・・・。
あ、かといって、それが聞いているとも限らないか。

しかし・・・debugに変更してもダメだった。
これだと思ったんだけどなぁ・・・。

休憩。

---

よくわからんが、gcc_startup_nrf51のスタートアップからSystemInit()に飛んだ後、

push {r7, lr}

とやってるんだが、これがだめみたい。
pushの引数はreglistで、pushしたいレジスタを並べるだけみたい。
push先は、SP(r13)。
今のSP=0x7c0。
nRF51822のメモリマップを見ると、RAMは0x2000_0000から始まっている。
でも、gcc_nrf51_s110_xxaa.ldでは、RAMは前と同じく0x2000_2000からになっている。

いやいや、もしSPの設定が間違ってるんだったら、デバッグ起動しようと通常起動しようと、動くはずがないじゃないか。
くー、悔しいけどわからない・・・。

---

まず、SPを疑ってみよう。

Cortex-M0の場合、SPのデフォルト値はベクタテーブルの先頭にある32bit値らしい。
スタートアップルーチンを見ても、SystemInit()を呼ぶまでの間にSPを設定している様子がないので、デフォルト値そのままなのだろう。

    .globl __Vectors
__Vectors:
    .long    __StackTop            /* Top of Stack */
    .long   Reset_Handler               /* Reset Handler */
    .long   NMI_Handler                 /* NMI Handler */
    .long   HardFault_Handler           /* Hard Fault Handler */

ベクタテーブルは、こんな感じ。
ふむ、悪くない。
では、値となる__StackTopはどうなっているか。
mapファイルで見よう。

.stack_dummy    0x20002de8      0x800
*(.stack*)
.stack         0x20002de8      0x800 _build/gcc_startup_nrf51.o
                0x20004000                __StackTop = (ORIGIN (RAM) + 0x2000)
                0x20003800                __StackLimit = (__StackTop - SIZEOF (.stack_dummy))

うーん、メモリマップから見てもまともだ。
でも、Vectorsのアドレスはgcc_nrf51_s110_xxaa.ldのFLASHなので、0x0001_6000なのだ(v7.0.0)。

じゃあ、起動時のベクタテーブルはどうなってるかというと、たぶん0x0000_0000。
そこは、SoftDeviceを書き込んでいるところなのか？

だめだ、今日はここまでだ。