基于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地址。

示例2訪問無效地址導致BusFault

這個例子中，地址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的原因，盡早發現代碼中的錯誤異常，從而提升開發和調試效率，提高代碼質量。

審核編輯 ：李倩