在進行CortexM系列MCU開發時，大家應該都或多或少觸發過不可屏蔽中斷，例如人見人愛的Hardfault。

對于嵌入式工程師來說，能夠穩定復現的Bug最好解決，再不濟挨個打斷點也能定位到問題代碼位置。

可是異常如果是不定時，無規律的發生在日常的運行中，那打斷點的方式無異于守株待兔。

本篇將提供小技巧簡述CortexM的異常壓棧機制，教大家如何寫出一個現場保存函數以及如何調用該函數。

如下圖所示，觸發中斷的時候，CortexM?系列芯片會按照該排列將相關現場數據進行地址偏移壓棧，N即此時的SP數值，通過SP中存放的地址，我們可以獲取到如圖所示的數據。

而要知道觸發異常的地址則需要關注LR（Link Register)的數值，它存放著異常觸發點的函數地址。

那么按照壓棧的排列，我們可以編寫一個結構體以及相關的記錄現場函數，如下圖所示，結構體的成員完全是按照上圖的壓棧順序排列，那下一步就是在哪里調用這個接口來獲取到案發時的第一手資料

?要想獲得第一手數據，就要去中斷函數的執行處，很多廠商的SDK都會在名為XXX_it.c文件里為開發者們寫好各個中斷的Handler，由于S文件中都是弱定義（弱定義即在C文件中有同名的函數，則以C文件中的函數優先編譯，則可能造成觸發中斷時并不會運行S文件處的函數）所以建議可以將其屏蔽或者自己重新編寫一個新的函數名。

由下圖可見，通過IMPORT的形式調用外部現場保存函數，將SP寄存器賦值給R0寄存器是因為R0通常時作為函數的第一個參數進行調用的，可看作是將SP數值作為參數傳入StackSave函數，BL的意思是帶返回的跳轉，即使跳轉運行完成StackSave函數后還返回此處。

完成上述函數編寫以及調用后，即可進行測試了。本次范例通過SPI初始化時傳入錯誤的外設寄存器地址來觸發HardFault中斷，由下圖可看出，此時記錄到的LR數值為0x8000e83

?查詢后可知，0x8000e83的位置為SPI初始化函數中，符合預設的異常觸發位置。在非仿真環境下可通過map文件找到大致的函數地址。

綜上，我們就知道了如何獲取到觸發異常中斷時的程序運行地址，通過將獲取到的信息存入到片上Flash指定地址的形式將此時的現場信息進行保存，并通過固件和map一一對應管控。

這樣在漫長運行過程中，如果不慎觸發異常異常中斷，通過對應的map文件即可迅速定位BUG所在大致位置?