在我们日常的项目中，我们可能会遇到死机的情况，通过在线调试或打印消息，我们可能会发现自己陷入了”HardFault_Handler”中断之中。

这种”硬故障”是我们常见的一种故障，也有许多原因导致了硬故障的发生。本文将重点探讨与Cortex-M3相关的Fault故障。

Fault故障的种类

Fault故障又分为多种类型，就拿本文的Cortex-M3来说，主要包括以下几种：

• HardFault：硬故障
• MemManage：存储器管理故障
• BusFault：总线故障
• UsageFault：用法故障

比如，在stm32f10x_it.c源代码中，有这样的中断入口：

void HardFault_Handler(void)
{
  /* Go to infinite loop when Hard Fault exception occurs */
  while (1)
  {
  }
}

void MemManage_Handler(void)
{
  /* Go to infinite loop when Memory Manage exception occurs */
  while (1)
  {
  }
}

void BusFault_Handler(void)
{
  /* Go to infinite loop when Bus Fault exception occurs */
  while (1)
  {
  }
}

void UsageFault_Handler(void)
{
  /* Go to infinite loop when Usage Fault exception occurs */
  while (1)
  {
  }
}

***Fault*故障描述

每一种Fault故障的产生，都肯定是有一定原因的，如果你代码产生了Fault故障中断，说明代码某些地方引起了Fault故障。

1.HardFault：硬故障

通过截图的描述，你会发现硬故障是一种“不可编程”的故障，因为存储器管理故障、总线故障、用法故障如果不能得到执行，就为上访为硬故障。

比如：比如在取向量时产生的总线故障也按会硬故障进行处理。所以，你会发现出现故障，很多时候都是硬故障。

硬故障状态寄存器描述：

通过状态寄存器，你会发现产生硬故障的原因有以上几种。

2.MemManage：存储器管理故障

存储器管理故障通常与MPU（内存保护单元）有关，之前给大家分享过MPU相关的文章《什么是Cortex-M内核的MPU？》。

通常就是我们说的“内存越界”就会导致存储器管理故障，细说引起该故障的诱因有：

• 访问了 MPU 设置区域覆盖范围之外的地址
• 往只读 region 写数据
• 用户级下访问了只允许在特权级下访问的地址

存储器管理故障状态寄存器：

通过状态寄存器，你会发现引起该故障的一些原因。

3.BusFault：总线故障

总线故障，顾名思义就是对“总线”操作出现问题，导致的故障。

比如：当 AHB 接口上正在传送数据时，如果回复了一个错误信号(error response)，则会产生总线故障。

产生总线故障的场合：

• 取指，通常被称作“预取流产”
• 数据读/写，通常被称作“数据流产”

触发总线故障的动作：

• 中断处理起始阶段的堆栈 PUSH 动作。称为“入栈错误”
• 中断处理收尾阶段的堆栈 POP 动作。称为“出栈错误”

同样，通过总线故障状态寄存器了解产生的原因：

4.UsageFault：用法故障

用法故障相对不常见，出现该故障通常是进行了“未对齐访问操作”，其他导致该故障问题很少见。

比如：执行了未定义的指令、除数为0（编译器都会避免）、无效的中断返回等这些情况比较少见。

用法故障状态寄存器：

应对故障

不知道大家平时有没有对这些进行有效避免？

这里简单说几点应对故障的措施：

1.通过故障状态寄存器的值来判定程序错误

在故障中断函数中，读取故障的状态（上面描述了状态寄存器），比如硬故障：

void HardFault_Handler(void)
{
  //读取状态寄存器，打印状态寄存器，判断什么原因引起故障
  printf("状态x信息");
  while (1)
  {
  }
}

如果不想系统处于死机状态，可以在中断里面做软复位。

2.提前对代码进行分析、预判

比如：通过代码静态分析工具，对代码进行分析、查找bug。

前不久才分享过一篇文章：推荐几个代码静态分析工具

3.其他诊断方法

之前给大家分享过一篇文章《针对Cortex-M调试诊断 HardFault 的错误追踪库》可以有效诊断本文说的这种“硬故障”。

先写到这里，还有更多更好的方法，欢迎大家留言补充