基于SRAM的STM32WLE5固件远程更新技术咨询

1. 利用SRAM中数据完成固件更新的实现方式 #

核心通过Bootloader（引导程序）完成Flash写入流程，步骤如下：

• 提前在Flash起始区域部署Bootloader：上电后优先运行Bootloader，负责固件更新逻辑。
• 自定义链路传输新固件到SRAM指定区域：需做数据校验（如CRC32、SHA-256）避免损坏固件写入Flash；若新固件体积超过SRAM容量（STM32WLE5 SRAM为64KB），需分块传输——每传一块到SRAM就写入Flash对应分区，再传输下一块。
• 解锁Flash写保护：调用HAL库HAL_FLASH_Unlock()或直接操作寄存器解锁。
• 擦除目标固件分区：根据新固件大小，擦除Flash中对应APP分区的页（STM32WLE5 Flash页大小为2KB）。
• 写入Flash：将SRAM中的固件数据按Flash页大小逐页写入目标分区。
• 锁定Flash并跳转：写入完成后调用HAL_FLASH_Lock()锁定，设置启动标志（如在Flash保留区写标记），再跳转到新固件的复位向量地址执行。

2. 仅从SRAM执行新固件，复位后回退到旧固件的可行性及实现 #

完全可行，适合临时测试或应急修复，实现步骤：

• 编译新固件为SRAM执行模式：修改链接脚本，将代码段、数据段映射到SRAM地址空间（STM32WLE5 SRAM起始为0x20000000），确保固件入口指向SRAM区域。
• Bootloader接收并校验固件：通过自定义链路将新固件完整传输到SRAM预留区域，校验完成后直接跳转到SRAM的复位向量（即0x20000004，0x20000000为栈顶地址）。
• 复位回退逻辑：SRAM数据复位后丢失，系统自动回到Flash中的Bootloader；Bootloader检测不到SRAM有效固件时，直接跳转到Flash旧固件入口执行。
• 注意：SRAM执行的固件无法使用依赖Flash的功能（如自修改代码），断电后固件丢失，仅适合临时运行。

3. IAP是否适用于该场景 #

完全适配，IAP（In-Application Programming）正是为应用内固件更新设计的机制：

• 传统IAP常用UART/USB等通道，你只需将自定义链路替换为数据传输通道即可。
• 推荐Flash分区方案：分为Bootloader区（起始区域，不可擦除）、APP_A区（当前旧固件）、APP_B区（待写入新固件）、数据保留区（存储配置等关键数据）。
• Bootloader核心逻辑：通过自定义链路接收新固件到SRAM，校验后写入APP_B区；启动时检测更新标志，有效则跳APP_B区，否则跳APP_A区；若新固件启动失败（可通过看门狗或启动标志判断），自动回退到APP_A区。

4. 无额外硬件/EEPROM下实现固件更新并保留特定数据 #

可以实现，依赖STM32自身Flash分区：

• 在Flash中划分独立的数据保留分区：该分区与Bootloader、APP分区物理隔离，更新固件时仅擦除APP分区，不触碰数据区。
• 存储关键数据：将需保留的配置参数、设备状态等写入该分区，读取时直接从对应Flash地址读取。
• 注意事项：
  • Flash擦除按页进行，数据分区需按Flash页大小（STM32WLE5为2KB）对齐。
  • Flash有约10万次擦写寿命，若频繁写入数据，需实现简单磨损均衡策略（如多页轮换存储，避免单页过度擦写）。
  • 临时保留数据可存在SRAM，但断电后丢失，长期存储必须用Flash分区。

内容的提问来源于stack exchange，提问作者Foreen