粉丝学习STM32 IAP升级遇到的问题

电子设计联盟 · 发表于 2024-11-19 08:01:00

wt2rxk0nxol64012789922.gif

点击上方蓝色字体，关注我们
来源于粉丝提问。

mzfvs0kzqow64012790022.png

0ug1jrywqiq64012790122.png

9 F4 ~0 H/ x" i

问题1：IAP的退出机制是通过跳转到业务APP实现的，实际上是“转移控制权”而非退出循环。

$ ~% w: S( I4 k/ R
问题2：你对复位需求的理解是对的，要实现“不复位更新”，需要调整架构，如在业务APP中集成IAP功能，或者通过双备份机制支持热更新。
1
问题1：IAP应用的while循环是怎么退出的？
在你提供的IAP程序代码中，while(1)是一个无限循环。从代码逻辑看，IAP应用的退出并没有显式的break语句。

它的退出依赖于以下逻辑：

当用户按下按键（代码中使用了key_get()），且满足相关条件时，会调用iap_load_app()函数。

iap_load_app()函数中完成了对目标APP的跳转操作。

跳转通过设置MCU的向量表和程序计数器（PC寄存器）完成，实际等同于切换到业务APP的代码空间并开始执行。

一旦跳转到业务APP，MCU的控制权就交给了业务APP，IAP程序实际上“停止”了，因为MCU不再执行IAP的指令。

本质上，IAP应用的退出依赖于代码跳转（跳转到新的程序入口点），而不是常规意义的循环退出。

因此，while(1)虽然没有显式退出，但程序已经通过跳转到新的APP实现了功能切换。
2
问题2：业务APP运行后，如何进行代码更新？

你的理解大体正确：在业务APP运行期间，IAP应用已经被“替换”，无法直接从业务APP切回到IAP应用。

根据这位粉丝提供的图片资料现有流程理解：

IAP应用作用：

IAP程序运行后，可以通过串口或其他接口接收新的业务APP文件，并将其烧录到FLASH指定区域。

烧录完成后，IAP应用跳转到业务APP的入口，业务APP开始运行。

问题描述：

在业务APP运行期间，业务APP接管了全部系统资源（如串口等），IAP程序不再运行，无法进行新业务APP的下载和烧录。

如果需要更新APP，只能通过复位MCU重新启动IAP程序，再次进入更新模式。
[/ol]
3
要实现“在业务APP运行期间，不复位，更新业务APP”的方法
这种需求可以通过设计实现，但需要对程序架构进行调整，以下是几个常见的解决方案：
0 Q) z: a: b9 @: a6 G8 W- X# U& x

方案1：业务APP中集成IAP功能
在业务APP中预留IAP功能代码，例如：

在业务APP运行时监听某个特殊信号（如通过串口发送特定指令）；

收到信号后，业务APP调用IAP功能模块完成新代码的下载和烧录；

烧录完成后，直接跳转到新的业务APP。
, ^2 z+ d5 S! X+ O. k3 E7 D

优点：业务APP运行期间即可完成更新，无需复位。

缺点：增加了业务APP的复杂性（需同时管理业务逻辑和IAP逻辑）。
" m/ f- ~6 l$ @3 b O

方案2：设计IAP与业务APP共存
通过MCU的FLASH分区管理，让IAP和业务APP同时存在于不同的区域，具体做法：

双区启动机制：

IAP程序在启动时检测用户输入或某个标志位。

如果需要更新，进入IAP模式接收新APP文件。

如果不需要更新，直接跳转到业务APP。

业务APP的重启机制：

在业务APP运行期间，监听串口信号，收到更新请求后通过软件触发复位（或设置标志位并复位）。

复位后重新进入IAP程序完成更新。
[/ol]8 O" x( D% G: z

优点：IAP程序简单，不会受到业务APP逻辑的影响。

缺点：仍然需要复位，但复位可以由业务APP通过软件触发（无须用户手动操作）。
7 { l3 A J: j

方案3：通过双备份机制实现热更新
部分高端MCU支持双备份机制，可以实现“热更新”，步骤如下：

IAP程序负责维护两个FLASH区域，分别存储当前运行的APP和待更新的APP；

当业务APP运行时，允许IAP程序后台烧录新的APP到备份区域；

烧录完成后，通过设置标志位通知系统下次启动时切换到新APP。
[/ol]
优点：支持后台更新，用户体验更好。

缺点：FLASH容量需求较大，需要支持双分区。

1fkoexeljw164012790222.jpg

ecc2pzkezci64012790322.gif

点击阅读原文，更精彩~