082、STM32Cube.AI的OTA更新案例从一次现场崩溃说起去年冬天，一个做工业振动监测的客户找到我。他们的设备部署在西北某风电场的塔筒里，用STM32F4跑着Cube.AI生成的模型，负责识别轴承早期故障。设备出厂时模型精度不错，但运行三个月后，现场反馈误报率飙升——新出现的故障模式模型没见过，而OTA更新功能一直没启用，只能派人爬塔筒拆机烧录。那趟差旅费够买几十片MCU了。这个案例让我意识到：TinyML的OTA不是“能不能做”的问题，而是“怎么做得稳”的问题。今天这篇笔记，就围绕STM32Cube.AI生成的模型，结合STM32的IAP（In-Application Programming）机制，拆解一个完整的OTA更新方案。代码基于STM32L4+FreeRTOS+MQTT，但思路通用于其他系列。模型OTA的底层逻辑STM32Cube.AI生成的模型，本质上是一组经过量化的权重数组和推理代码。在MDK-ARM或STM32CubeIDE编译后，模型数据会链接到特定的Flash地址段。OTA更新的核心，就是用新模型的二进制数据覆盖旧模型所在的Flash区域。这里有个关键点：Cube.AI生成的模型通常放在.nn_model段或自定义段，而不是和主程序混在一起。这意味着我们可以只更新模型段，而不动主程序代码——这比整包OTA风险小得多，也快得多。我习惯的做法是：在链接脚本（.ld文件）中为模型数据单独划分一个Flash扇区。以STM32L476为例，Flash共1MB，每