zephyr死机原因追踪

lbaihao

已于 2022-08-28 10:18:01 修改

阅读量731

点赞数

分类专栏： zephyr物联网文章标签：驱动开发

于 2022-01-23 14:16:05 首次发布

本文链接：https://blog.csdn.net/lbaihao/article/details/122650974

版权

zephyr物联网专栏收录该内容

47 篇文章 25 订阅

订阅专栏

STM32 HardFault解决方法，参考资料《Cortex-M3/M4权威指南》

现象还原：在debug模式下进行仿真调试，全速运行再停止运行，程序会跑到 HardFault_Handler函数中，产生 HardFault，即硬错。其产生的原因大概有如下几类：

(1)数组越界操作；

(2)内存溢出，访问越界；

(3)堆栈溢出，程序跑飞；

(4)中断处理错误；

针对HardFault问题的定位，网上有几种方法，大概都是围绕着：在debug模式下，查看一些地址，分析寄存器、函数调用栈等，这是很让人头疼的事情。这里分享一种简单的、直观的HardFault错误定位的方法，使用开源库：CmBacktrace 。

CmBacktrace简介

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

支持的错误包括：
- 断言（assert）
- 故障（Hard Fault, Memory Management Fault, Bus Fault, Usage Fault, Debug Fault）
故障原因 自动诊断 ：可在故障发生时，自动分析出故障的原因，定位发生故障的代码位置，而无需再手动分析繁杂的故障寄存器；
适配 Cortex-M0/M3/M4/M7 MCU；
支持 IAR、KEIL、GCC 编译器；

移植及使用（keil）

CmBacktrace 源码地址：

GitHub - armink/CmBacktrace: Advanced fault backtrace library for ARM Cortex-M series MCU | ARM Cortex-M 系列 MCU 错误追踪库

把cm_backtrace文件夹复制到我们的工程目录下，并添加至keil工程中，并添加头文件、勾选C99模式：

此时，编译会产生几个错误：

那是因为有些预处理宏没有找到，打开、修改cmb_cfg.h文件的内容。cmb_cfg.h文件默认内容为：

我们修改后的cmb_cfg.h内容变为：

这时候编译还会有一个错误，cmb_fault.c与stm32f10x_it.c中的HardFault_Handler函数重定义：

需要把stm32f10x_it.c中的HardFault_Handler函数屏蔽掉：

这时候就可以编译通过了。下面我们来看看这个库的效果。

我们编写如下测试函数：

/*******************************************************************************************************
** 函数: 错误追踪库测试入口
**------------------------------------------------------------------------------------------------------
** 参数: void
** 返回: 无
** 说明：
********************************************************************************************************/
void fault_test_entry(fault_test_case_E _test_case)
{
    switch (_test_case)
    {
        case FAULT_TEST_BY_DIV0: 
            fault_test_by_div0();
        break;

        case FAULT_TEST_BY_UNALIGN: 
            fault_test_by_unalign();
        break;

        default: 
            printf("test case error!\n");
        break;
    }
}

/*******************************************************************************************************
** 函数: 除0测试
**------------------------------------------------------------------------------------------------------
** 参数: void
** 返回: 无
** 说明：
********************************************************************************************************/
static void fault_test_by_div0(void) 
{
    volatile int * SCB_CCR = (volatile int *) 0xE000ED14; // SCB->CCR
    int x, y, z;

    *SCB_CCR |= (1 << 4); /* bit4: DIV_0_TRP. */

    x = 10;
    y = 0;
    z = x / y;
    printf("z:%d\n", z);
}

复制

然后在主函数中调用测试函数：

下载运行程序：

可以看到，列出的信息很详细，包括出错原因。按照它的提示，我们运行命令：

addr2line -e stm32f10x_demo.axf -a -f 0800162a 080016b7 08001719

复制

运行这个命令需要用到addr2line.exe工具，这个工具在CmBacktrace源码目录下的tools文件夹中：

有32bit和64bit两个版本，根据我们的环境选择，并拷贝到我们的keil工程目录下可执行文件.axf所在的文件夹中：

在这个文件中进入到cmd窗口，方法：按下Shift键的同时点击鼠标右键：

运行上面那条命令：

可以看到addr2line.exe工具给我们定位出了错误相关的代码行号，我们看看对应行的代码是什么：

对应的行号正是出错的地方。

可以看到，使用这个CmBacktrace 库能帮助我们有效、快速地定位到HardFault之类的错误。addr2line命令后面跟着几个地址就是错误相关的地址，这几个地址可以牵扯的内容很深，如果我们不使用CmBacktrace 库，我们可能就得自己去分析这些偏底层的内容了。

zephyr死机原因追踪_wanjietiam的博客-CSDN博客

该项目程序使用ucos-ii，键盘驱动作为其中一个任务。

键盘驱动本身不难，使用基础的扫描方式。难的是调试时发现程序总会进入hardfault。

hardfault是M3和M4内核的一种机制，具体类型可以百度“HardFault的诊断”。

接下来说说我艰苦的调试过程。。。

首先百度了怎么调试hardfault，根据这篇文章http://www.cnblogs.com/Ilmen/p/3356147.html描述的方法试了起来。

过程并没有那么顺利。首先根据keil的fault report知道了我的错误类型也是usage fault中的INVSTATE，所以是尝试进入ARM状态所导致的hardfault。

然后找到发生hardfault之前PSP里的LR，然后查看该地址的汇编指令，并没有发现什么不妥，所以一下子又没了思路。。。

于是调试只能往更细致的方向去了，我发现在某个地方进入了系统延时函数就会发送错误，于是我在一些关键的函数里设置断点，包括OSShed()、OSCtxSw()、PendSV_Handler()这些与任务调度密切相关的函数。

接着发现，在系统企图将任务切换到键盘任务时就会出错。这时我便在要调度的之前，单步执行，在这个过程也更深入了解了任务切换时堆栈如何压入和弹出。最后发现问题是切换到键盘任务后函数返回的PC错了！而我再反顺序看这些数据是如何入栈的，发现入栈时是对的，也就是在数据在后来的过程中被破坏了！
然后我又接着设置断点、单点调试。。最终发现是在下一个任务的数据入栈时被破坏了。

到此原因就很清晰了，是因为下一个任务的堆栈大小设置过小，导致数据入栈时越界，破坏到键盘任务的堆栈了。

过程有点繁琐，因此也写得繁琐，希望遇到类似困难的朋友能得到一点启发^_^。在这个过程中我的体会就是：一要了解内核的机制；二要不怕苦和繁琐，大胆去探索底层的执行过程（分析汇编指令）。