查找哪個指令在Cortex M3上造成陷阱

Question

我目前正在使用Keil uVision調試一個硬故障陷阱，事實證明這是STM32F205 Cortex-M3處理器上的精確數據總線錯誤。 由於冗長的調試和谷歌搜索過程，我發現了引起陷阱的匯編指令。 現在，我正在尋找一種方法來避免下次發生陷阱時的冗長過程。

在Keil的應用筆記209中說：

PRECISEERR：精確的數據總線錯誤：0 =沒有精確的數據總線錯誤1 =發生數據總線錯誤，並且為異常返回而堆疊的PC值指向引起故障的指令。 當處理器將該位置1時，它將故障地址寫入SCB-> BFAR

還有這個：

異常會將寄存器R0-R3，R12，PC和LR的狀態保存到主堆棧或過程堆棧中（取決於發生異常時使用的堆棧）。

我在解釋的最后一個引號中應有7個寄存器以及相應的堆棧。 當我在內存中查找我的SP地址時，我看到了導致錯誤的地址，該地址比堆棧指針地址高10個字。

我的問題是：

Answer 1

如您所說，ARM Cortex-M3上的異常（或中斷）將自動堆疊一些寄存器，即：

程序計數器（PC）

處理器狀態寄存器（xPSR）

R0-R3

R12

鏈接寄存器（LR）。

對於總共8個寄存器（請參考： Cortex™-M3技術參考手冊，第5.5.1章）。

現在，如果您使用匯編語言以外的語言編寫異常處理程序，則編譯器可能會堆疊其他寄存器，您無法確定有多少個。

一種簡單的解決方案是在實際處理程序之前添加一小段代碼，以傳遞自動堆棧寄存器的地址：

void myRealHandler( void * stack );

void handler(void) {
    asm volatile("mov r0, sp");
    asm volatile("b myRealHandler");
}

寄存器BFAR特定於總線故障。 它包含錯誤地址，而不是錯誤指令的地址。 例如，如果讀取地址0x30005632的整數時0x30005632 ，則BFAR將設置為0x30005632 。

Answer 2

返回地址的確切堆棧位置取決於中斷處理程序需要多少堆棧。 如果您看一下HardFault_Handler的反匯編，則除了硬件中斷機制（R0-R3，R12，PC， LR和PSR）

我發現這是一個關於調試Hard Faults的好主意，盡管它需要一些內聯匯編。