Nordic の SDK はマクロ山盛りで見通しが藪の中。
SEGGER Embedded Studio (SES) を使ってマクロを辿る方法。

環境

SEGGER Embedded Studio for ARM V4.18
Ubuntu 18.04

事例

SDK nRF5_SDK_for_Thread_and_Zigbee_v4.0.0_dc7186b
の examples - zigbee - experimental 中の、「multi_sensor」

を改造していたら、


<info> app: Production configuration is not present or invalid (status: -1)
<info> app: Production configuration is not present or invalid (status: -1)
<info> app: Production configuration is not present or invalid (status: -1)

というのがずっと出るようになってしまいました。

デバッガで追うとm ain.c の以下の箇所で発生していることがわかりました。


while(1)
    {
        zboss_main_loop_iteration();
        UNUSED_RETURN_VALUE(NRF_LOG_PROCESS());
    }

この UNUSED_RETURN_VALUE(NRF_LOG_PROCESS());
を実行するとデバッガで追えなくなりループ表示がはじまる。

    UNUSED_RETURN_VALUE(NRF_LOG_PROCESS());

は何をやっているのかな？
該当行を SES 上で右クリックし

Go To Definition または
Go To Declaration

を選択すると、以下のように表示される

読んでみると、単に ((void)(NRF_LOG_PROCESS()))を意味しているだけだった。
今度は NRF_LOG_PROCESS() を右クリックし Go To Definition を選ぶと
nrf_log_ctrl.h に切り替わり該当する以下が表示される。


# define NRF_LOG_PROCESS()    NRF_LOG_INTERNAL_PROCESS()

NRF_LOG_INTERNAL_PROCESS() を更に追うと

nrf_log_ctrl_internal.hの

# define NRF_LOG_INTERNAL_PROCESS() nrf_log_frontend_dequeue()

となり、
nrf_log_frontend_dequeue() を右クリックし Go To Definition を選ぶと

nrf_log_frontend.c の


bool nrf_log_frontend_dequeue(void)

が出るので
そこにブレークポイントを設定しデバッグできる

事例の顛末

なお、今回は

UNUSED_RETURN_VALUE(NRF_LOG_PROCESS());

を追っていったが肝心のメッセージが出る原因はここではなかったようだ。
それ以前に実行設定された Zigbee スレッドからのシグナル処理の結果、以下の箇所で出力されるらしい。

更に、メッセージが無限ループするのはソフトの問題ではなく、ハードウェアの問題で起動直後にリセットがかかっていたのが原因でした。

お騒がせ様！