實(shí)戰(zhàn)經(jīng)驗(yàn) | TrustZone 架構(gòu)下 LPBAM 使用導(dǎo)致的 HardFault

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

目錄預(yù)覽

1、簡(jiǎn)介

2、問題分析

3、總結(jié)

01

簡(jiǎn)介

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

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

02

問題分析

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

圖2.程序下一步將 Hardfault

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

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

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

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

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

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

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

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

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

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

03

總結(jié)

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

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