STM32U5 OTFDEC 加密引发图片撕裂？原因拆解与解决办法

在基于 STM32U5（如 STM32U585OIY6QTR）的项目开发中，不少开发者会遇到一个棘手问题：调用 OTFDEC 加密外部 Flash 数据后，显示器显示的图片出现明显撕裂。这个问题看似诡异 —— 加密区域与图片存储区域已严格划分，理论上互不干扰，为何会影响显示？本文结合意法半导体 LAT1646 技术文档与实际开发经验，从原理到实操，彻底讲透问题根源与解决方案。

资料获取：经验分享 | LAT1646 一个关于STM32U5 OTFDEC加密数据的问题

1. 问题现象：加密操作后图片莫名撕裂

实际项目里，外部 SPI Flash 常被划分为两个独立区域：一区存储 GUI 显示用的图片素材，二区存储需加密的日志数据。开发中发现，一旦调用HAL_OTFDEC_Cipher函数加密日志数据，屏幕图片立即出现水平撕裂、花屏等异常；停止加密后，显示恢复正常。更奇怪的是，此时尚未执行 Flash 写入操作，仅调用加密函数就触发了显示问题。

2. 根源深挖：OTFDEC 加密的 “隐藏操作”

要解决问题，需先理清 OTFDEC 的工作逻辑与 HAL 函数的底层实现。

2.1 OTFDEC 核心功能

OTFDEC（即时解密模块）是 STM32U5 的安全外设，核心作用是实时解密外部 SPI Flash 中的加密只读数据，也支持加密模式（AES128 CTR）。它可定义 4 个独立加密区域，每个区域配备独立密钥与配置，仅对指定区域生效，非加密区域不受影响。

2.2 GUI 显示与 OTFDEC 的唯一交集

STM32U5 的 GUI 显示流程为：MCU 从外部 Flash 读取图片数据→写入 RAM 处理→像素数据传输至显示器。整个过程与 OTFDEC 的唯一交集是外部 Flash 与 AHB 总线—— 两者都需占用总线访问外部存储。

2.3 HAL_OTFDEC_Cipher的 “反常识” 实现

查看 HAL 库源码与 RM0456 参考手册发现：HAL_OTFDEC_Cipher函数并非直接执行 AES 加密运算，而是封装了一套特殊的加密流程：

• OTFDEC 加密模式下，需以 32bit 为单位，向目标外部 Flash 地址写入明文数据；
• 从同一地址读回数据，此时 OTFDEC 硬件自动拦截并完成 AES 加密，读回的数据即为密文；
• 所有数据加密完成后，将 RAM 中缓存的密文回写至外部 Flash。

这意味着，调用HAL_OTFDEC_Cipher时，会频繁发起外部 Flash 的读写操作，直接占用 AHB 总线带宽。而图片渲染同样依赖 AHB 总线读取 Flash 图片数据，总线冲突导致图片数据传输不完整，最终出现撕裂。

3. 解决思路：资源互斥，优先保障显示

问题核心是多任务共享 AHB 总线与外部 Flash 资源引发的冲突。图片显示属于高优先级任务，需优先保障；OTFDEC 加密为后台任务，可在显示间隙执行。因此解决方案的核心是对外部 Flash 操作加互斥锁：

1. 当图片渲染任务运行时，锁定外部 Flash，禁止其他任务（如 OTFDEC 加密）访问；
2. 图片渲染完成后，释放锁，允许 OTFDEC 加密任务执行 Flash 读写；
3. 加密任务仅在锁空闲时运行，避免与显示任务抢资源。

4. 实操效果：加锁后问题彻底解决

客户按上述方案修改代码，在图片渲染任务启动时添加 Flash 互斥锁，加密任务中增加锁状态检测（仅锁释放时执行加密）。测试结果显示：调用 OTFDEC 加密日志数据时，图片显示不再出现撕裂，系统运行稳定，加密功能也正常生效。

STM32U5 的 OTFDEC 加密功能强大，但开发者需注意其加密模式的底层操作 ——加密过程依赖外部 Flash 读写，会占用 AHB 总线。在同时涉及 GUI 显示与 OTFDEC 加密的项目中，必须做好共享资源的互斥管理，优先保障高优先级任务（如显示）的资源占用，避免总线冲突导致的异常。