RTT小师弟 · 2021年04月22日

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等,大大提高程序的移植性、可调试性,能提高调试的效率。
推荐阅读
关注数
8072
内容数
181
小而美的物联网操作系统,经过14年的累积发展,RT-Thread 已经拥有一个国内最大的嵌入式开源社区,同时被广泛应用于能源、车载、医疗、消费电子等多个行业,累积装机量超过4亿台,成为国人自主开发、国内最成熟稳定和装机量最大的开源 RTOS。
目录
极术微信服务号
关注极术微信号
实时接收点赞提醒和评论通知
安谋科技学堂公众号
关注安谋科技学堂
实时获取安谋科技及 Arm 教学资源
安谋科技招聘公众号
关注安谋科技招聘
实时获取安谋科技中国职位信息