如何调试nRF5 SDK (二）

fugoog

Keil IDE

通过以下方式打开nRF5 SoC内部寄存器查看窗口：

用得比较多的几个Keil窗口：

Segger embedded studio IDE

SES的调试界面如下所示（跟Keil很像）：

这里要特别强调一下，所有SES工程都包含2个版本：Release版和Debug版，Release是没有包含debug信息以节省代码空间，所以如果你要debug一个工程，请先选择debug版本，然后再进行debug，如下所示：

3. nRF5 SDK自带的APP_ERROR_CHECK函数

APP_ERROR_CHECK是nRF5 SDK定义的一个用来检查API返回值是否正确的函数，在nRF5 SDK中，NRF_SUCCESS（0）为正确返回值，其它返回值皆为错误值。nRF5 SDK所有协议栈API调用，以及SDK库函数调用，都会用APP_ERROR_CHECK去检查调用的返回值。当出现非法调用时，比如传入的实参不对，API返回值就不会为NRF_SUCCESS，此时APP_ERROR_CHECK就会派上大用场。通过查看APP_ERROR_CHECK函数定义，如下所示：

NRF_BREAKPOINT_COND;// On assert, the system can only recover with a reset.#ifndef DEBUGNRF_LOG_WARNING("System reset");NVIC_SystemReset();#elseapp_error_save_and_stop(id, pc, info);#endif // DEBUG

你会发现APP_ERROR_CHECK行为受宏DEBUG和有没有挂仿真器两个因素的影响，当没有定义DEBUG宏时，系统将直接产生软复位；当定义了DEBUG宏并且没有挂仿真器时，系统将把错误信息保存在call stack中。不管怎么配置，APP_ERROR_CHECK都会把相应的错误信息打印出来，以方便你去排查问题，如下所示。通过打印出来的错误信息，你就可以知道是哪个文件哪一行代码出了什么类型的错误。

注意在SDK14以前，app_error_check不会主动把错误信息打印出来，而是把错误信息存在RAM中，然后通过debug模式可以直接查看相关错误信息，如下所示：

默认情况下，nRF5 SDK是没有定义DEBUG宏的，所以一旦函数返回值不对，系统就会复位。这里要特别指出的是，在你开发调试过程中，经常会碰到复位的情况，这其中大部分都是由APP_ERROR_CHECK引起的。针对这种情况的复位，你只需要在options for target->C/C++->define里面定义一个宏：DEBUG，就可以快速找出是哪一个文件哪一行代码引出的复位，以及复位原因是什么，如下所示：

4.使用命令行（CLI）方式进行调试

打log方式只能单方面输出，而不能接受终端的输入，在很多情况下，我们需要动态调整log信息，比如动态更改log的级别，动态更改log的颜色等等，这个时候就需要用到nrf_cli模块，跟nRF_Log相似，nrf_cli同时支持5种后端接口：UART，RTT，BLE，Flash和USB CDC。由于nrf_cli也有log输出功能，因此nRF_Log模块可以直接选择nrf_cli为其后端接口。这里再次强调一下，nrf_log和nrf_cli是两个完全独立的模块，但是nrf_log可以选用nrf_cli为其后端接口，由nrf_cli完成后端打印功能。SDK中提供了三个cli的例子，分别为：

• \examples\peripheral\cli\pca10040\blank\arm5_no_packs
• \examples\ble_peripheral\experimental\ble_app_cli\pca10040\s132\arm5_no_packs
• \examples\ble_central_and_peripheral\experimental\ble_app_interactive\pca10040\s132\arm5_no_packs
  

如果大家的应用需要命令行交互方式，可以参考上面3个例子，以examples\peripheral\cli\pca10040\blank\arm5_no_packs为例，交互成功后的界面如下所示：