上个月产线反馈回来一批设备，大概每两百台里有三台在出厂前最后一次固件升级时卡死。症状很统一：升级进度条走到某个随机位置停住，上位机提示“连接超时”，设备端则安静地躺在引导程序里，像块砖头。返修记录写的是“重新烧录即可恢复”，但没人深究为什么升级会断，断了之后为什么恢复不了。这种问题在实验室几乎复现不出来。实验室的线材短、供电稳、电磁环境干净，而产线工装夹具的线缆拖了三四米，旁边还有电机在间歇启停。连接中断本身不稀奇，稀奇的是中断之后设备没有回到一个可再次升级的状态，而是彻底失联。我后来花了两个晚上把引导程序的升级状态机翻出来逐行看，才发现问题出在一个很隐蔽的地方：引导程序在擦除应用程序分区之前，会把“升级标志”写进非易失存储区，但擦除完成后、写入新固件之前，这个标志一直没有被更新。如果此时连接断开，设备重启后读到“升级标志有效”，会再次进入升级模式等待上位机握手。听起来没问题对吧？但坏就坏在，引导程序等待握手的超时时间设置得极短，只有两秒。产线工装上的上位机在检测到连接断开后，重新打开串口、重新初始化协议栈、再发出握手包，这一套流程走完往往超过两秒。于是设备在超时后直接跳转到应用程序区，而应用程序区已经被擦干净了，里面全是空指令，取指必然出错，硬件异常处理程序又把设备复位，复位后引导程序再次读到升级标志有效，再次进入升级模式，再次超时，再次跳转，再次硬件异常——一个死循环。设备看起来就像死机了，连看门狗都救不回来，因为复位后立刻又进入了这个循环。这个坑让我意识到，固件升级的恢复策略不能只考虑“连接断开”这一个事件，还要考虑断开之后设备端状态机的行为，以及上位机重连的节奏。两者之间的时间窗口如果对不上，恢复就变成了死循环。升级状态机里最容易被忽略的三个时间窗口
