RT-Thread 利用笔记 - 不正确应用LOG也会引发hard fault

RT-Thread 利用笔记 - RTC Alarm 组件的应用

RT-Thread 利用笔记 - freemodbus RTU RS485 从机

RT-Thread 利用笔记 - freemodbus RTU RS485 主机

RT-Thread 利用笔记 - libmodbus RTU RS485 从机

RT-Thread 利用笔记 - libmodbus RTU RS485 主机

RT-Thread 利用笔记 - STM32 CAN 通信双机

RT-Thread USB学习实际系列
背景

最近在调试RT-Thread的代码时，应用了LOG_D这样的基于串口输入的调试形式进行调试信息或错误信息的打印。调试的LOG输入，在代码公布时，不须要逐行的正文掉，只须要更改DBG_LEVEL，能够【一键敞开所有LOG，或LOG分级过滤输入】，大大提高调试效率。大部分的代码，是调试进去的，LOG是比拟实用的调试办法。

DEBUG LOG开启的形式如下：

define DBG_ENABLE

define DBG_SECTION_NAME "main"

define DBG_LEVEL DBG_LOG

include <rtdbg.h>

DEBUG LOG 的应用办法如下：

void dump_system_clk(void)
{

LOG_D("%s:SysClockFreq=%d, HCLKFreq=%d,PCLK1Freq=%d,PCLK2Freq=%d\n",        __func__,        HAL_RCC_GetSysClockFreq(),        HAL_RCC_GetHCLKFreq(),        HAL_RCC_GetPCLK1Freq(),        HAL_RCC_GetPCLK2Freq());

}

MSH_CMD_EXPORT(dump_system_clk, dump system clock);

问题形容

为了不便，咱们喜爱在调试的时候，把函数名与行号都打印进去，__func__, __line__等。然而，如果打印时，后面的打印格局：如%s：%d,%d,%d，前面的参数，没有一一对应好，就会引发各种问题！！轻点的：打印的不对，有乱码。重大的：hardfault。如果后期没有标准LOG输入，前期标准了，但遗记一一测试LOG的输入，某个参数巨多的LOG输入，要额定留神下。如果LOG_E这样的，个别不会进入触发，但非凡条件触发了，呈现了因为打印引发的【hard fault】。如果你基本分不革除是代码引起的，还是LOG输入引起的，调试起来很头疼。我过后敞开LOG后，测试没问题，开启LOG后，在【排雷】过程中，发现，本人在LOG_D时，多了个%s，或者少了个__func__，就会呈现了【hardfault】。通过重复的确认代码，发现没有异样，最终找到原来是打印时，少了参数。所以，代码编写，须要仔细。

问题复现

参数多了，可能脱漏__func__，多加了%d，等等，须要认真对待。例子：以下为漏了__func__：

void dump_system_clk(void)
{

LOG_D("%s:SysClockFreq=%d, HCLKFreq=%d,PCLK1Freq=%d,PCLK2Freq=%d\n",        HAL_RCC_GetSysClockFreq(),        HAL_RCC_GetHCLKFreq(),        HAL_RCC_GetPCLK1Freq(),        HAL_RCC_GetPCLK2Freq());

}

执行MSH cmd命令后：

msh >dump_system_clk
[D/main] psr: 0x01000000
r00: 0x04c4b400
r01: 0x04c4b400
r02: 0x04c4b400
r03: 0x20003ed4
r04: 0x2000161c
r05: 0x00000000
r06: 0x2000171b
r07: 0xffffffff
r08: 0x2000161c
r09: 0xffffffff
r10: 0xdeadbeef
r11: 0xdeadbeef
r12: 0x00000001
lr: 0x0800f0cf
pc: 0x0800dd32
hard fault on thread: tshell

thread pri status sp stack size max used left tick error

emq_pms 28 suspend 0x0000007c 0x00000800 08% 0x0000002c 000
tshell 20 running 0x00000084 0x00001000 07% 0x0000000a 000
serial 25 suspend 0x00000088 0x00000400 13% 0x00000007 000
tidle0 31 ready 0x00000050 0x00000800 05% 0x0000000a 000
main 10 suspend 0x0000009c 0x00000800 41% 0x0000000c 000
bus fault:
SCB_CFSR_BFSR:0x82 PRECISERR SCB->BFAR:04C4B400

问题解决

加强LOG输入时的查看，格式化输入时，参数的数量、格局，解决好。修复的办法：补充上__func__即可！！LOG_D、 LOG_I、LOG_E等调试信息输入，是用来定位程序问题的，自身不能成为问题。

总结：

代码调试中，遇到各种【诡异】的问题，只有仔细，总能找到【精确】的解释或【正确】的答案。代码编写，仔细，调试，仔细，能力产出高质量的代码。正确应用LOG_D、 LOG_E等，大大提高程序的移植性、可调试性，能进步调试的效率。