1. 问题背景  

客户在开发STM32U5 SBSFU过程中，原本APP_NS使用了整个SRAM3的512K大小

的内存，但后来由于需求变更，要将SRAM3中前32K的内存分给APP_S用。客户调整代码

后，发现触发了SecureFault中断。尝试查找问题所在，但一直没找到。

本文将基于此问题背景，向读取呈现如何调试并定位一个trustzone相关问题的过程，以

增加读者的调试经验。

2. 问题分析与定位

从客户那拿到可以重现问题的测试代码。烧录并运行代码，从打印信息确实看到程序运行

不正常。因为正常情况下APP_NS的打印信息是可以看到的，但此时并没有。

用STM32Cueprogrammer hotplug模式连上去看下PC值 :

图 1 内核寄存器值

                   

从上图的内核寄存器可以看出，IPSR=7，说明发生了SecureFault, 当前PC指向地址

0xC01AF1A.

图 2 编程手册中的IPSR定义

SBSFU 共有boot, APP_S, APP_NS, Loader_S, Loader_NS, 这几个工程，与此问题相关

的其实只有boot, APP_S, APP_NS。

从STM32CubeIDE的Build Analyzer窗口中可知，这三个工程的Flash地址范围为 :

Boot :

图 3 BOOT的Flash,RAM占用情况

图 4 APP_S的flash, RAM占用情况

图 5 APP_NS的flash,RAM占用情况

PC 指向地址0xC01AF1A, 可知程序当前运行在APP_S内，且处于SecureFault中断内。

配置调试参数为不复位不下载的方式，联调APP_S, APP_NS这两个工程:

图 6 程序进入到SecureFault中断内

此时查看SAU_SFSR寄存器内容：

   

图 7 SAU寄存器内容

从上图可知，此时触发了AUVIOL，它意味着违反了SAU规则，且SFARVALID=1,即此

时SFAR寄存器生效，它指出了具体哪个位置违背了规则.

图 8 编程手册中AUVIOL, SFARVALID的定义说明

从图7中得知SFAR=0x2004bf70, 即触发secureFault的具体位置，它指向SRAM3，到

底是什么东西呢？             

虽从SFSR.AUVIOL明确指出了此问题是由于违背了SAU规则导致，为保险起见，我们还

是检查下MPCBB3的配置：

图 9 MPCBB3的配置

从上图可知，SRAM3的前两个super block(32KB)被设置为Secure属性,其余的为

NonSecure 属性，这与预期相符，并没有明显问题。

于是我们停止调试，准备查看下0x2004 bf70这个位置到底指向啥数据？ 结果在

APP_NS中查看Build Analyzer 窗口中找到此位置的信息：

图 10 0x2004 bf70 位于stack中

从图中可知，0x2004 bf70这个位置它处于APP_NS的主栈中。我们再调试下，看看代

码具体是如何触发此SecureFault的？

图 11 程序进入到APP_NS的Reset_Handle中断入口时触发了SecureFault

通过调试，最终发现当程序跳转到APP_NS工程的Reset_Handle中断入口处，当执行完

第一行代码把当前寄存器压入栈时则立即触发了SecureFault中断。由于之前SAU_SFSR寄

存器指出了此SecureFault是由于违背了SAU规则导致，于是查看当前8个SAU region的

配置:

注：在”REGION”后面输入栏内手动输入对应序号后才能查看各个region的内容

图 12 SAU region0配置

图 13 SAU region1配置

图 14 SAU region2配置

图 15 SAU region3

            

图 16 SAU region4配置

图 17 SAU region5配置

                 

图 18 SAU region6配置

图 19 SAU region7配置(没有配置)

通过查看上面8个SAU region的配置后可知，除了region 7没有配置外，与

0x2004 bf70 这个位置相关的region只有region2和region3, 且这两个region还是重

复定义的。其定义的范围都是一模一样，且均是定义为NonSecure. 即便是重复的，那完

全可以删除掉其中一个。于是我们删除掉region3 :

在APP_S工程中，将宏SAU_INIT_REGION3关闭：

#define SAU_INIT_REGION3    0

然后重新编译后再测试下，结果发现程序恢复正常运行！                    

意不意外？！我们不禁要问，为什么？

通过查阅相关文档，最终在Cortex-M33编程手册PM0264 Rev 3的第4.5.1节中找

到如下内容：

如上所述，任何地址如何匹配到多个 SAU region，则被认为是最高安全的。即便它原

本被定义是NonSecure属性。感觉这个有点坑，但没办法，ARM就是这么定义的规则。

3. 结束语

本文所描述的问题，客户其实是花了大量精力来设计，MPCBB3配置，SAU配置，代码区域

划分，内存区域划分，ld文件配置等等，但始终没找到问题所在，最终问题还是出在了一个

毫不起眼的 “小问题”上，可见有关trustzone开发上，仔细阅读相关手册，细心和耐心是

相当重要的。

---

重要通知 - 请仔细阅读 意法半导体公司及其子公司 （“ST”）保留随时对 ST 产品和 / 或本文档进行变更的权利，恕不另行通知。买方在订货之前应获取关于 ST 产 品的最新信息。 ST 产品的销售依照订单确认时的相关 ST 销售条款。 买方自行负责对 ST 产品的选择和使用， ST 概不承担与应用协助或买方产品设计相关的任何责任。 ST 不对任何知识产权进行任何明示或默示的授权或许可。 转售的 ST 产品如有不同于此处提供的信息的规定，将导致 ST 针对该产品授予的任何保证失效。 ST 和 ST 徽标是 ST 的商标。若需 ST 商标的更多信息，请参考 www.st.com/trademarks。所有其他产品或服务名称均为其 各自所有者的财 产。 本文档是ST中国本地团队的技术性文章，旨在交流与分享，并期望借此给予客户产品应用上足够的帮助或提醒。若文中内容存有局限或与ST 官网资料不一致，请以实际应用验证结果和ST官网最新发布的内容为准。您拥有完全自主权是否采纳本文档（包括代码，电路图等）信息， 我们也不承担因使用或采纳本文档内容而导致的任何风险。 本文档中的信息取代本文档所有早期版本中提供的信息。 © 2020 STMicroelectronics - 保留所有权利