[nrf52][nfc]ようやく1つめのブレークポイントに当たる

nRF52でNFCペアリングをしようとして、assertが発生していると言うことはわかった。
問題は、その次だ。
どこが失敗してassertを発生させているのだろう？

これが、経過した地点のUARTなり何なりのログが出ればわかるのだけど、assertしたら何も出ていない今ではそれができない。
J-Linkのブレークポイントも、同時に4つくらいまでしか設定ができない(ハードウェアブレーク、の制約かな)。

なので、少ない労力で、これは！というところにブレークポイントを設定して、当ててやりたい。
そうしたい気持ちの半分は「めんどくさいから、さっさと当たってほしい」で、もう半分は「動物的勘であててやる！」というものだ。
後者の方が半分以上あるとは思う。

 

今回選んだのは、device_manager_peripheral.cのdevice_instance_find()。
「Searching for device」というログがUARTに出ていたからだ。
ここでm_peer_table[]というテーブルのアドレス情報と、引数のp_addrのアドレス情報を比較しているようだ。
そして一致すればよいのだが、一致しなければエラーで抜ける。
じゃあ、エラーになってるんじゃないの？ということで、条件分岐を追加してブレークポイントを設定した。
ソースが提供されてるって、こういうときいいよね。

そして、そのブレークポイントに止まった。
nRF52 Preview DKが保持していると思われるアドレス情報と、引数でもらってきたアドレス情報が一致していないのだ。
それは、だめだろうという気がする。

しかし、だ。
nRF52 Preview DKが保持していると思われるm_peer_table[]には、Nexus5の設定画面で表示されるBluetoothのアドレスと一致している。
一致していないのは、引数で渡されたアドレスの方だ。
引数で渡されるということは、接続時などに相手から渡されるアドレス情報とかじゃないんだろうか？
そのときに、Nexus5に固有のアドレスを使うのでは無く、ランダムなアドレスを使っているとか、そんなことではなかろうか。

そんなわけで、次はBLEの無線を捕捉して、引数で渡されるアドレス情報との関連を見つけていくことになろうか。
いやあ、長いなぁ。