本文將講述Nordic nRF5 SDK的主要調(diào)試手段，以幫助大家快速定位問(wèn)題，并解決問(wèn)題。一般來(lái)說(shuō)，你可以通過(guò)打log方式，IDE的debug模式，SDK自帶的app_error_check函數(shù)，以及命令行方式等多種手段來(lái)調(diào)試你的代碼。

1. 通過(guò)打log方式進(jìn)行調(diào)試

nRF5 SDK支持UART和SWD J-Link（RTT）兩種底層通信方式來(lái)打印日志，SDK14之后日志也可以通過(guò)藍(lán)牙或者Flash進(jìn)行輸出和存儲(chǔ)打印，一般來(lái)說(shuō)，UART和SWD用得比較多，其中UART使用串口助手來(lái)查看日志，SWD使用J-Link RTT Viewer（僅適用Windows）或者J-Link RTT Client（Windows/Mac/Linux系統(tǒng)）來(lái)查看打印日志。由于UART日志打印方式會(huì)占用一個(gè)UART口，而大部分nRF5芯片都只有一個(gè)UART口，從而導(dǎo)致資源沖突，為此推薦大家使用RTT方式來(lái)打印日志，從而可以將UART口留給正常應(yīng)用，更重要的是RTT打印方式功耗非常低（幾乎可以忽略不計(jì)），大家可以在正式release的產(chǎn)品中也使能它，從而發(fā)現(xiàn)產(chǎn)品部署后有可能會(huì)出現(xiàn)的問(wèn)題（UART打印方式功耗非常高，在正式release產(chǎn)品中必須關(guān)掉它）。

如果使用SWD接口進(jìn)行日志打印，那么你可以使用J-Link RTT Viewer或者RTTClient來(lái)顯示日志，二者選其一即可。在Windows平臺(tái)推薦使用RTT viewer，否則使用RTT Client。

1.1 J-Link RTT Viewer

RTT viewer配置方式如下所示：

RTT viewer日志打印窗口如下所示：（使用的是SDK15.3中的ble_app_hrs例子，下同）

1.2 J-Link RTTClient

RTT client配置方式如下所示（直接使用jlink命令進(jìn)行配置）：

RTT client打印窗口如下所示：

1.3 UART串口助手

串口助手配置方式如下所示：

Baud rate: 115200

8 data bits

1 stop bit

No parity

HW flow control: None

隨便選擇一款你熟悉的串口助手，比如Putty或者Termite，Termite打印窗口如下所示：

Putty打印窗口如下所示：

1.4 日志打印模塊nRF_Log

nRF5 SDK日志打印功能是通過(guò)nRF_Log模塊實(shí)現(xiàn)的（上面展示的日志都是通過(guò)nRF_Log打印出來(lái)的），SDK包含的大部分例子都自帶打印功能，也就是說(shuō)包含了nRF_Log模塊。一般來(lái)說(shuō)，例子都是默認(rèn)使用UART進(jìn)行打印的，如果需要改為RTT進(jìn)行打印，需要對(duì)nRF_Log模塊進(jìn)行配置。在具體講述nRF_Log模塊的配置選項(xiàng)之前，先大概講述一下nRF_Log的工作原理。

nRF_Log工作原理

nRF_Log模塊包含前端和后端兩部分代碼。前端是面向用戶的打印接口，比如NRF_LOG_INFO，它把用戶要打印的數(shù)據(jù)放在一塊RAM中。后端用來(lái)具體實(shí)現(xiàn)打印功能，即把前端RAM中的數(shù)據(jù)通過(guò)不同的后端接口打印出去。目前nRF_Log支持的后端接口有：UART，RTT，F(xiàn)lash和藍(lán)牙。不管采用哪一種后端接口，對(duì)用戶來(lái)說(shuō)，其調(diào)用的前端API是一樣的，nRF_Log模塊會(huì)根據(jù)用戶的配置自動(dòng)適配相應(yīng)后端接口，而且用戶可以同時(shí)使能多個(gè)后端接口，即把日志同時(shí)打印到多個(gè)后端端口上。nRF_Log模塊可以單獨(dú)使能或禁止某一個(gè)模塊的打印功能，比如advertising模塊，當(dāng)你調(diào)試advertising模塊的時(shí)候，可以把log打開(kāi)，調(diào)試完畢，把log關(guān)閉以讓log界面變得更清爽。nRF_Log模塊還可以設(shè)置打印的級(jí)別（Level），如果不分級(jí)別的話，打印界面會(huì)包含很多打印信息，讓我們每次調(diào)試都要花費(fèi)很多時(shí)間去尋找自己想要的日志上。設(shè)定級(jí)別后，我們可以有選擇的打印需要的日志信息，沒(méi)問(wèn)題時(shí)，我們只打印info級(jí)別的日志；有問(wèn)題時(shí)，我們就可以把所有debug級(jí)別的日志都打印出來(lái)。nRF_Log還有一個(gè)功能：Deferred，如果不使能Deferred，那么調(diào)用NRF_LOG_INFO等API的時(shí)候，立馬就Flush，即把日志打印出去；如果使能了Deferred，那么調(diào)用NRF_LOG_INFO等API的時(shí)候，只是把打印數(shù)據(jù)放在RAM中，真正的打印由main函數(shù)中的NRF_LOG_PROCESS完成，這樣可以最大程度降低打印對(duì)應(yīng)用本身的影響，尤其在執(zhí)行一些時(shí)序很關(guān)鍵的操作的時(shí)候。nRF_Log還支持時(shí)間戳打印，即在每條日志之前加上時(shí)間戳信息。

nRF_Log配置

從SDK12以后，nRF_Log模塊的配置主要放在sdk_config.h文件中，以工程nRF5_SDK_15.3.0_59ac345examplesble_peripheralble_app_hrspca10040s132arm5_no_packs為例，nRF_Log的配置選項(xiàng)如下所示：

注意：nRF5 SDK v11.0.0及以前版本是沒(méi)有sdk_config.h文件的，此時(shí)你需要到options for target->C/C++->define里面定義一個(gè)宏（Keil工程），如果定義“NRF_LOG_USES_UART=1”選擇UART日志打??；如果定義”NRF_LOG_USES_RTT=1” 則選擇RTT日志打印，如下：

還是以nRF5_SDK_15.3.0_59ac345examplesble_peripheralble_app_hrspca10040s132arm5_no_packs為例，當(dāng)nRF_Log配置為info級(jí)別，無(wú)timestamp，打印信息如下（與前面配置一樣）

當(dāng)nRF_Log配置為debug級(jí)別，打開(kāi)timestamp，打印信息如下所示：

2. 使用IDE調(diào)試界面進(jìn)行調(diào)試

Nordic產(chǎn)品支持單步，斷點(diǎn)，寄存器查看，內(nèi)存查看，call stack查看等所有常規(guī)調(diào)試手段。需要注意的是，由于softdevice在底層要維持一定的時(shí)鐘以及處理很多中斷事件，一旦藍(lán)牙跑起來(lái)后，只能用一個(gè)斷點(diǎn)進(jìn)行全速跑，也就是說(shuō)，執(zhí)行完一個(gè)斷點(diǎn)后，程序內(nèi)部邏輯和時(shí)序已經(jīng)紊亂，此時(shí)不能再繼續(xù)全速跑第二個(gè)斷點(diǎn)。如果要看第二個(gè)斷點(diǎn)的內(nèi)容，只能刪掉第一個(gè)斷點(diǎn)，重新開(kāi)始執(zhí)行。

Keil IDE

通過(guò)以下方式打開(kāi)nRF5 SoC內(nèi)部寄存器查看窗口：

用得比較多的幾個(gè)Keil窗口：

Segger embedded studio IDE

SES的調(diào)試界面如下所示（跟Keil很像）：

這里要特別強(qiáng)調(diào)一下，所有SES工程都包含2個(gè)版本：Release版和Debug版，Release是沒(méi)有包含debug信息以節(jié)省代碼空間，所以如果你要debug一個(gè)工程，請(qǐng)先選擇debug版本，然后再進(jìn)行debug，如下所示：

3. nRF5 SDK自帶的APP_ERROR_CHECK函數(shù)

APP_ERROR_CHECK是nRF5 SDK定義的一個(gè)用來(lái)檢查API返回值是否正確的函數(shù)，在nRF5 SDK中，NRF_SUCCESS（0）為正確返回值，其它返回值皆為錯(cuò)誤值。nRF5 SDK所有協(xié)議棧API調(diào)用，以及SDK庫(kù)函數(shù)調(diào)用，都會(huì)用APP_ERROR_CHECK去檢查調(diào)用的返回值。當(dāng)出現(xiàn)非法調(diào)用時(shí)，比如傳入的實(shí)參不對(duì)，API返回值就不會(huì)為NRF_SUCCESS，此時(shí)APP_ERROR_CHECK就會(huì)派上大用場(chǎng)。通過(guò)查看APP_ERROR_CHECK函數(shù)定義，如下所示：

NRF_BREAKPOINT_COND;

// On assert, the system can only recover with a reset.

#ifndef DEBUG

NRF_LOG_WARNING("System reset");

NVIC_SystemReset();

#else

app_error_save_and_stop(id, pc, info);

#endif // DEBUG

你會(huì)發(fā)現(xiàn)APP_ERROR_CHECK行為受宏DEBUG和有沒(méi)有掛仿真器兩個(gè)因素的影響，當(dāng)沒(méi)有定義DEBUG宏時(shí)，系統(tǒng)將直接產(chǎn)生軟復(fù)位；當(dāng)定義了DEBUG宏并且沒(méi)有掛仿真器時(shí)，系統(tǒng)將把錯(cuò)誤信息保存在call stack中。不管怎么配置，APP_ERROR_CHECK都會(huì)把相應(yīng)的錯(cuò)誤信息打印出來(lái)，以方便你去排查問(wèn)題，如下所示。通過(guò)打印出來(lái)的錯(cuò)誤信息，你就可以知道是哪個(gè)文件哪一行代碼出了什么類型的錯(cuò)誤。

注意在SDK14以前，app_error_check不會(huì)主動(dòng)把錯(cuò)誤信息打印出來(lái)，而是把錯(cuò)誤信息存在RAM中，然后通過(guò)debug模式可以直接查看相關(guān)錯(cuò)誤信息，如下所示：

默認(rèn)情況下，nRF5 SDK是沒(méi)有定義DEBUG宏的，所以一旦函數(shù)返回值不對(duì)，系統(tǒng)就會(huì)復(fù)位。這里要特別指出的是，在你開(kāi)發(fā)調(diào)試過(guò)程中，經(jīng)常會(huì)碰到復(fù)位的情況，這其中大部分都是由APP_ERROR_CHECK引起的。針對(duì)這種情況的復(fù)位，你只需要在options for target->C/C++->define里面定義一個(gè)宏：DEBUG，就可以快速找出是哪一個(gè)文件哪一行代碼引出的復(fù)位，以及復(fù)位原因是什么，如下所示：

4.使用命令行（CLI）方式進(jìn)行調(diào)試

打log方式只能單方面輸出，而不能接受終端的輸入，在很多情況下，我們需要?jiǎng)討B(tài)調(diào)整log信息，比如動(dòng)態(tài)更改log的級(jí)別，動(dòng)態(tài)更改log的顏色等等，這個(gè)時(shí)候就需要用到nrf_cli模塊，跟nRF_Log相似，nrf_cli同時(shí)支持5種后端接口：UART，RTT，BLE，F(xiàn)lash和USB CDC。由于nrf_cli也有l(wèi)og輸出功能，因此nRF_Log模塊可以直接選擇nrf_cli為其后端接口。這里再次強(qiáng)調(diào)一下，nrf_log和nrf_cli是兩個(gè)完全獨(dú)立的模塊，但是nrf_log可以選用nrf_cli為其后端接口，由nrf_cli完成后端打印功能。SDK中提供了三個(gè)cli的例子，分別為：

examplesperipheralclipca10040blankarm5_no_packs

examplesble_peripheralexperimentalble_app_clipca10040s132arm5_no_packs

examplesble_central_and_peripheralexperimentalble_app_interactivepca10040s132arm5_no_packs

如果大家的應(yīng)用需要命令行交互方式，可以參考上面3個(gè)例子，以examplesperipheralclipca10040blankarm5_no_packs為例，交互成功后的界面如下所示：

審核編輯 黃宇