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。
我们深知加工与定制类服务商的价值和重要性,因此,我们倾力为您提供最顶尖的营销资源。在我们的平台上,您可以直接接触到100万的研发工程师和采购工程师,以及10万的活跃客户群体...详细>>