STM32 CmBackTrace 移植与使用

前言：

在使用STM32 开发时，避免不了各种异常导致进入hardfault。通常如果进入hardfault 的错误容易复现好解决，直接debug调试即可。就怕hardfault 需要几天才能复现，这个时候总不能一直接连电脑debug等着它复现吧，因此需要一个工具能够定位 hardfault 错误，将进入while(1)循环之前将现场的环境保存下来，并且将这些数据通过串口打印或者存储到内部flash，后面在读取出来。

HardFault 产生原因

常见产生HardFault产生的原因大概有如下几类：

• 数组越界操作；
• 内存溢出，访问越界；
• 堆栈溢出，程序跑飞；
• 中断处理错误。

数组溢出

毋庸置疑，程序中使用了静态数组，而在动态传参时数组赋值溢出。或者动态分配内存太小，导致程
序异常。

内存溢出

重点检查RAM区域，程序编译后执行的RAM数据量大小为多少是否可能越界。一般不要设置到极致
的情况，程序中的一些动态数组传参时会导致异常。

计算 RW-data+ZI-data 为需要存储在RAM区域的变量等。
检查程序编译后的.MAP文件。
对应手册，或者编译器查找到对应RAM存储空间区域。找到该区域分析，并对应。

在这种问题下，尤其需要注意：
使用Printf， vsprintf， sprintf 格式化数据导致的内存问题，这些函数使用的内存空间较大，猜测是由
于，该函数采用的拷贝数组的形式转换，内存耗费剧烈。
使用操作系统的若为 设置钩子函数抛出异常，则也会产生该问题。配置操作系统所用空间，包含消
息量，消息队列，邮箱，任务堆栈等。

堆栈溢出

这在使用操作中问题尤其严重，在操作系统中，任务的变量均分配放置在任务所申请的堆栈空间中。
例如FreeRTOS的xTaskCreate、 task. h
创建新的任务并添加到任务队列中，准备运行
Parameters
pvTaskCode
指向任务的入口函数. 任务必须执行并且永不返回 (即：无限循环).
pcName
描述任务的名字。主要便于调试。最大长度由configMAX_TASK_NAME_LEN.定义
usStackDepth
指定任务堆栈的大小 ，堆栈能保护变量的数目- 不是字节数. 例如，如果堆栈为16位宽度，
usStackDepth定义为 100, 200 字节，这些将分配给堆栈。堆栈嵌套深度（堆栈宽度）不能超多最
大值——包含了size_t类型的变量
pvParameters
指针用于作为一个参数传向创建的任务
uxPriority
任务运行时的优先级( 0 : 优先级最低)
pvCreatedTask
用于传递一个处理——引用创建的任务
返回:
pdPASS 是如果任务成功创建并且添加到就绪列中，另外错误代码在projdefs. h文件定义.
所创建的任务需要指定堆栈大小，那么堆栈申请不足，则会出现异常，针对该问题可启动系统的钩子
函数HOOK函数，抛出该异常。

中断处理异常

程序中开启了某些中断，例如USART,TIMER,RTC等。
但在程序执行中，满足中断条件，但并未能查找到该部分对应的中断服务函数，则可能会出现该异
常

HardFault 分析方法

常见的分析方法是：发生异常后之后，首先查看LR寄存器中的值，确定当前使用堆栈为MSP或PSP,然后找到相应堆栈的指针，并在内存中查看相应堆栈里的内容。由于异常发生时，内核将R0-R3、R12 Returnaddress、PSR、LR寄存器依次入栈，其中 Return address即为发生异常前PC将要执行的下一条指令地址。

CmBacktrace

CmBacktrace （Cortex Microcontroller Backtrace）是一款针对 ARM Cortex-M 系列 MCU 的错误代码自动追踪、定位，错误原因自动分析的开源库。主要特性如下：

• 支持的错误包括：
  • 断言（assert）
  • 故障（Hard Fault, Memory Management Fault, Bus Fault, Usage Fault, Debug Fault）
• 故障原因 自动诊断 ：可在故障发生时，自动分析出故障的原因，定位发生故障的代码位置，而无需再手动分析繁杂的故障寄存器；
• 输出错误现场的 函数调用栈（需配合 addr2line 工具进行精确定位），还原发生错误时的现场信息，定位问题代码位置、逻辑更加快捷、精准。也可以在正常状态下使用该库，获取当前的函数调用栈；
• 支持 裸机 及以下操作系统平台：
  • RT-Thread
  • UCOS
  • FreeRTOS（需修改源码）
• 根据错误现场状态，输出对应的 线程栈 或 C 主栈；
• 故障诊断信息支持多国语言（目前：简体中文、英文）；
• 适配 Cortex-M0/M3/M4/M7 MCU；
• 支持 IAR、KEIL、GCC 编译器；

基于 MDK 的 CmBacktrace 库使用流程

基于MDK的移植方法按如下步骤进行：

步骤一 添加cm_backtrace库文件到MDK中

把cm_backtrace文件夹复制到我们的工程目录下，并添加至keil工程中。

步骤二 添加头文件、勾选C99模式

步骤三 编译和调试

首先， cmb_cfg.h文件按以下提示配置修改。

这时候编译有一个错误， 这是因为cmb_fault.c与at32f4xx_it.c中的HardFault_Handler函数重定义：

需要把at32f4xx_it.c中的HardFault_Handler函数屏蔽掉。

初始化 cm_backtrace



这里的Appname 需要与输出的文件名一致。

将异常信息写入内部flash

正常如果设备有串口，进入hardfault 时会将错误信息打印出来，如果没有串口的话，我们就需要将错误信息写入内部flash，通过读取内部flash信息就可以知道上一次进入 hardfault 时的状况，然后再使用 addr2line工具查看错误代码。

添加写入flash信息代码：

这样下次可以通过st-link 定位到固定地址读取信息。