1. 前言
某客户使用 STM32U59，批量生产时发现有 1%左右的机器存在反复重启问题；问题机器断电后用热风枪加热 STM32U59 再上电问题消失，试了几台机器都是如此，遂怀疑STM32U59 存在质量隐患。

& Z( w' _6 C6 `
2. 调研
" u/ S: s2 m  B6 k7 Q% R把做过加热试验后正常的机器放入温箱降温再重新上电，但并没有出现反复重启现象。调整思路，请客户再提供一台仍能复现问题且未经加热的机器，尝试用 debugger 去跟踪代码执行，发现 debugger 一连上就断开。
修改量产代码：在 main( )前插入一个死循环 while(1)并烧录，问题机器不再复位；再烧录原始量产代码，问题又复现；确定问题由执行了某些代码引起。
再次烧录带死循环的代码，连上调试器重置 PC 指针后，按照正常流程执行。发现客户代码在判断 TZEN 未被置位后会尝试编程 Option Byte 来置位 TZEN，随后执行HAL_FLASH_OB_Launch()后引起 STM32U59 复位，这个本属于正常复位，引起调试器连接断开也是可预期的；但 MCU 重启后检查 Option Byte 发现 TZEN 并未被置位。

, j# _, u1 u; j
3. 分析
检查客户应用代码，发现其调用了 Cube 库 HAL 接口，但并未检查返回值。
单步执行跟踪 HAL 库代码执行情况，发现 pFlash- >Lock = 0x01（HAL_LOCK）导致后续 Option Byte 写入动作未被执行。取消 run to main 选项再复位 STM32U59，发现此变量不受全局变量初始化代码执行影响，无论手动将其设置为什么值，手动复位 MCU后，代码执行到操作 OptionByte 时，此变量仍保持复位前人为设置的值。
机器下电，用热风枪加热 PCB 一分钟再上电，连接调试器；程序扔停在死循环处，但此变量值变成了 0（HAL_UNLOCKED），再继续单步执行代码发现 HAL 对 OptionByte编程返回，再次检查 Option Byte 确认 TZEN 确实已置位。
5 }! n: _( d; K+ D* m8 d, J# N& I对比 Cube 原始代码与客户代码，发现客户除了将变量 pFlash 定位到了外部 RAM外，还人为修改其属性为__no_init 使得程序复位后不会对其初始化，这个变量的初值0x01 就是对应存储器存储单元在器件上电后的随机值，而加热单片机的同时也一起加热了PSRAM，升温碰巧使得此变量对应的 PSRAM 存储单元在上电时变成了 0x00（HAL_UNLOCKED），进而使得代码执行成功并置位了 TZEN；此后无论 MCU 怎么复位，由于代码检测到了 TZEN 已置位，也就不再主动调用 HAL_FLASH_OB_Launch()引发 MCU 复位。

1 r: ?9 c- J& I  x! T
- e  j2 o8 o$ g1 }" u' D* m3 u
" h5 u7 q( ]) ]7 F完整版请查看：附件



$ s9 M) s) w) L* x
( w; i9 r6 g; D8 \