關(guān)鍵詞：TrustZone，HardFault

目錄預(yù)覽

1、簡介

2、問題分析

3、總結(jié)

01

簡介

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

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

02

問題分析

通過斷點和單步調(diào)試，我們發(fā)現(xiàn)出現(xiàn)問題的指令如下所示：

圖2.程序下一步將 Hardfault

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

圖3.程序不會發(fā)生 Hardfault

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

然后繼續(xù)查找了 VLSTM 這條指令相關(guān)的描述，關(guān)于 VLSTM 在 PM0264 中有以下描述：

圖4.關(guān)于 VLSTM 指令

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

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

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

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

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

03

總結(jié)

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

完整內(nèi)容請點擊“閱讀原文”下載原文檔。