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 等，大大提高程序的移植性、可调试性，能进步调试的效率。