[nrf52][nfc]やはりassertしていた

nRF52のNFCペアリングをデバッグ中。
まだMakefileを仕立てるほどの気力がないので、Keilでやっている。
最適化しさえすれば、32KBに収まっているので大丈夫だ(95%使用、と出てくるが)。

シリアルログを出してみたが、どうもペアリングできないときはnRF52が再起動しているようだ。
自分のmain.cにapp_error_handler()を再定義してブレークポイントを張ったところ、止まったのだ。
ではコールスタックを見てみよう、というところで、Keilのコールスタックに見慣れておらず、ここにメモを残しておこうと思ったのだ。

---

コールスタックは、こんなウィンドウに出てくる。
下から順に呼んでいて、一番上が最新のものになっている。

それは普通なのだが、ツリーを展開するとこうなった。
スタックの中身も含めて表示してくれるようなのだ。

例えば、app_error_handler()は引数を3つ取る。

void app_error_handler(uint32_t error_code, uint32_t line_num, const uint8_t *p_file_name)

変数名の左に付いているアイコンのうち、矢印が付いているものが引数のようだ。

また、関数名をダブルクリックしてもジャンプはしてくれず、ツリーが開閉するだけ。
飛びたいときは、右クリックする。

「Caller」か「Callee」の選択となる。

「Callee]を選ぶと、コンテキストを表示した関数に飛ぶ。
ブレークした関数であれば、ブレーク位置。
誰かを呼び出したのであれば、呼び出した直後の位置。

「Caller」を選ぶと、自分が呼ばれる前の関数に飛ぶ。
「私はこの人から呼ばれました」という意味のCallerか。

今回を例に取ろう。
ble_evt_dispatch()で右クリックし、「Caller」を選択すると、その呼び元であるintern_softdevice_events_execute()に飛んだし、「Callee」を選択すると、次に呼び出す関数dm_ble_evt_handler()の次にカーソルが当たった。

---

これで追っていこうとしたのだが、最適化がしっかりかかっているためか、未使用の引数はかなり省略しているようだ。
おかげで、assertしたらLEDを光るようにしていたから飛んだことまではわかるものの、どういうエラーだったかなどは取って来れなかったのだ。

せめて、UARTのログに出すくらいはしておかないといかんな。