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

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