關鍵詞：TrustZone，HardFault

目錄預覽

1、簡介

2、問題分析

3、總結

01

簡介

客戶使用 STM32U5 進行開發，并使能了 TrustZone 架構，程序需要從 bootloader 跳轉到app。在之前版本都是正常跳轉的，某一天 IAR 從 9.20 升級到 9.30 后，程序跳轉失敗,并且會導致 hardfault，想知道為什么會失敗。

圖1.IAR9.20 和 IAR9.30 生成的匯編代碼對比

02

問題分析

通過斷點和單步調試，我們發現出現問題的指令如下所示：

圖2.程序下一步將 Hardfault

而沒有發生 hardfault 的版本匯編代碼，如下圖：

圖3.程序不會發生 Hardfault

通過單步調試，我們知道了 VLSTM SP 這條指令導致了 hardfault。接著我們再確認下 SP 指針，錯誤版本的 SP 的內容為：0x300020b4，正確版本的 SP 內容為：0x30000258。首先，我們對比了生成的 map 文件中 stack 的地址信息，發現其中 Stack 的地址和這里 SP 指令是相符的。

然后繼續查找了 VLSTM 這條指令相關的描述，關于 VLSTM 在 PM0264 中有以下描述：

圖4.關于 VLSTM 指令

從上圖可以看到，VLSTM SP 這條指令會把安全的浮點運算寄存器的值保存到 SP 地址中，并清除安全浮點寄存器的內容，如果 CPU 的狀態是非安全的，那么這條指令相當于空指令，也不會導致 hard fault，所有從這里也還是分析不出為什么會導致 hard fault。

重新回到這條指令，現在問題可能比較大的就是 SP 的地址了。有問題的版本的 SP 內容為：0x300020b4，會不會是對齊導致的呢？

基于這個猜測，我們直接在 IAR 界面強制修改了 SP 的地址為 0x300020b8，并繼續單步執行，然后程序可以正常執行了。所以目前所知的結論就是 VLSTM SP 這條指令，要求 SP 必須 8 字節對齊，可能 IAR 在編譯的時候并沒有注意到這一點。

然后，把這些信息反饋到 IAR 以后，IAR 的工程師回復如下：

根據目前的信息，問題應該是在 VLSTM 要求 8 字節對齊上。在 9.30.1 中，由于 PUSH.W {R4, R5, R7-R11}指令執行后，相當于占用了 28 個字節的棧空間，導致了 SP 和 9.20.1 相比，不是 8 字節對齊。

03

總結

在調試 TrustZone 工程的時候，由于使用了新的架構及新的匯編指令，需要對這些指令有一定基本的了解。在調查問題的時候，可以進行單步調試來定位發生問題的指令，然后再繼續深入了解下為什么會導致 hardfault。

完整內容請點擊“閱讀原文”下載原文檔。