在IAR Embedded Workbench for Arm中调试Cortex-M HardFault

基于Cortex-M的MCU被广泛应用于各种嵌入式系统中，Cortex-M有很多优点，比如高性能、低功耗、高代码密度、丰富的调试功能、强大的生态系统等。在错误异常处理上，Cortex-M提供了强大的错误异常机制，帮助提升系统的稳健性。

本文主要介绍如何在IAR Embedded Workbench for Arm中调试Cortex-M HardFault，帮助开发人员在开发过程中尽早发现代码中的错误异常、提升开发和调试效率、提高代码质量。

关于 Cortex-M Fault

Cortex-M包含了如下几种Fault:

• HardFault: 在异常处理中发生错误导致的Fault，或者是不能被其它异常处理的Fault。

• MemManage Fault: 违反内存访问规则导致的Fault。

• BusFault: 内存访问过程中总线出错导致的Fault。

• UsageFault: 指令执行时出错导致的Fault，包括：

- 未定义的指令

- 非法未对齐访问

- 指令执行时非法状态

- 异常返回错误

下面两个需要额外使能：

- 未对齐访问字和半字内存

- 除零操作

其中，HardFault是永远使能的，而MemManage Fault，BusFault和UsageFault默认是没有使能的，对应的Fault发生之后会升级为HardFault。

在IAR Embedded Workbench for Arm中调试Cortex-M HardFault

下面通过几个示例介绍如何在IAR Embedded Workbench for Arm中调试Cortex-M HardFault。

示例1：除零操作导致UsageFault

这个例子中，通过配置CCR寄存器中的DIV_0_TRP来使能除零操作异常。在Call Stack窗口中，可以看到对应发生除零操作的源代码行。在Register窗口中，可以看到 CFSR 寄存器中的DIVBYZERO 置位，表示出现了除零操作异常。在Debug Log和Fault exception viewer窗口中，可以看到详细的错误信息：发生了除零操作异常，导致UsageFault，由于UsageFault没有使能，升级为HardFault，同时给出了除零操作异常发生的PC地址和LR地址。

这个例子中，地址0x7000000是MCU中的无效地址，当访问无效地址时，会产生BusFault。在Call Stack窗口中，可以看到访问无效地址的源代码行。在Register窗口中，可以看到CFSR 寄存器的的PRECISERR和BFARVALID置位，表示出现了Precise data bus error，同时BFAR中保存了对应访问的无效地址。在Debug Log和Fault exception viewer窗口中，可以看到详细的错误信息：发生了precise data access error，导致BusFault，由于BusFault没有使能，升级为HardFault，同时给出了precise data access error发生时的PC地址和LR地址及对应访问的无效地址。

示例3：从XN（Execute Never）内存运行程序导致MemManage Fault

在这个例子中，地址0x4000000在Cortex-M中是属Peripheral地址空间，对应的内存属性属于XN（Execute Never）：即如果从XN内存运行程序会造成MemManage Fault。在Call Stack窗口中，可以看到对应的源代码行。在Register窗口中，可以看到CFSR 寄存器的的IACCVIOL置位，表示发生了instruction access violation。在Debug Log和Fault exception viewer窗口中，可以看到详细的错误信息：XN访问违反导致MemManage Fault，由于MemManage Fault没有使能，升级为HardFault，同时给出了XN访问发生时的PC地址和LR地址， 通过LR地址可以找到之前函数调用的地方（即导致MemManage Fault的地方）。

1. 为了在调试时出现Fault之后程序能够立即停下来，从而可以更好地分析出现Fault之后的现场，需要使能对应的Vector catch选项（默认是使能的）：关于Vector catch的更多信息，请参考ARMv7-M Architecture Reference Manual。

2. 本文中的示例是基于Cortex-M4，其它Cortex-M的错误异常机制可能会有所不同（比如基于ARMv6-M的Cortex-M0/M0+/M1只有HardFault，没有MemManage Fault，BusFault和UsageFault）,对应Register窗口中的信息可能与上面的截图不同，具体取决于所使用的 Cortex-M 类型。但是本文的方法适用于所有Cortex-M的HardFault调试。

本文以Cortex-M4为例，介绍了如何在IAR Embedded Workbench for Arm中调试Cortex-M HardFault。通过分析Call Stack，Register，Debug Log和Fault exception viewer窗口中的信息，可以快速地找到HardFault的原因，尽早发现代码中的错误异常，从而提升开发和调试效率，提高代码质量。

英文版