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的代码时,使用了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等,大大提高程序的移植性、可调试性,能提高调试的效率。