MCU通过UART实现OTA在线升级流程

关注+星标公众,不错过精彩内容

0a074c2ae834ce3f1b05b000844bf307.jpeg

素材来源 | 网络

OTA升级已经不是什么新鲜事,现在大多数物联网终端设备,基本具备这个功能。

今天以AT32为例给大家分享一下OTA升级的详细流程。

概述

空中下载技术OTA(Over-the-Air Technology)是用户自己的程序在运行过程中对User Flash的部分区域进行烧写,目的是为了在产品发布后可以方便地通过预留的通信口,对产品中的固件程序进行更新升级。通常实现OTA功能时,即用户程序运行中作自身的更新操作,需要在设计固件程序时编写两个项目代码,第一个项目程序为Bootloader区域,第二个项目程序App代码为真正的功能代码,执行应用和升级。这两部分项目代码同时烧录在User Flash中。

图1. OTA代码执行流程

5e59b0c866eb831f9d3c75130fb7b4c5.jpeg

在上图所示流程中,MCU复位后,从0x08000004地址取出复位中断向量的地址,并跳转到复位中断服务程序,在运行完复位中断服务程序之后跳转到Bootloader的main函数,如图标号①所示;在执行完Bootloader以后(App代码为图中FLASH灰底部分App程序的复位中断向量起始地址为0x08000004+N+M),跳转至App程序的复位向量表,取出App程序的复位中断向量的地址,并跳转执行App程序的复位中断服务程序,随后跳转至App程序的main函数,如图标号②和③所示,同样main函数为一个死循环,并且注意到此时AT32的FLASH,在不同位置上,共有两个中断向量表。

在main函数执行过程中,如果CPU得到一个中断请求,PC指针仍强制跳转到地址0x08000004中断向量表处,而不是App程序的中断向量表,如图标号④所示;程序再根据我们设置的中断向量表偏移量,跳转到对应中断源新的中断服务程序中,如图标号⑤所示;在执行完中断服务程序后,程序返回main函数继续运行,如图标号⑥所示。

通过以上两个过程的分析,我们知道OTA程序必须满足两个要求:

1) App程序必须在Bootloader程序之后的某个偏移量为x的地址开始。

2) 必须将App程序的中断向量表相应的移动,移动的偏移量为x。

AT32 USART OTA 快速使用方法

硬件资源

文档中是用AT-START-AT32F403A实验板的硬件条件为例,OTA demo源代码还包括AT32其他型号,用户只需编译对应型号工程烧录于AT-START实验板运行即可。

1) 指示灯LED2/LED3/LED4

2) USART1(PA9/PA10)

3) AT-START实验板

软件资源

1) tool_release

● IAP_Programmer.exe,PC机tool,用于演示OTA升级流程

2) source_code

● Bootloader,Bootloader源程序,运行LED2闪烁

● App_led3_toggle,App1源程序,运行LED3闪烁

● App_led4_toggle,App2源程序,运行LED4闪烁

注:工程基于keil v5建立,若用户需要在其他编译环境上使用,请参考对应BSP目录AT32F403A_407_Firmware_Library_V2.x.x\project\at_start_f403a\templates中各种编译环境(例如IAR6/7/8,keil 4/5,eclipse_gcc)进行对应修改即可。

OTA Demo 使用

本文档描述了两种常用的OTA应用demo,template app和dual app,后面章节会分别介绍。

1) 打开Bootloader工程源程序,选择对应MCU型号的target编译后下载到实验板

2) 打开IAP_Programmer.exe

3) 选择正确的串口、APP下载地址和bin文档,点击Download下载,如下图

4) 观察LED2/3/4闪烁,LED2闪烁-Bootloader工作,LED3闪烁-App1工作,LED4闪烁-App2工作

图2. IAP demo上位机

96b8e1b8487d8213b4632a6aa48c7f96.jpeg

Template app OTA程序设置

地址分布

图3. Flash地址分配

a9b9104ec9adc5deb76d471b2eb22312.jpeg

注:Bootloader区域最后一个扇区,用于存放防止升级过程出错(掉电等异常情况)的flag,用户编译修改Bootloader时,要保证不覆盖flag的地址。

执行流程

OTA分为Bootloader、App和Template三部分,应用在App中执行,Template仅作为新App固件数据的临时存放空间。程序执行整体流程框图如下:

图4. 程序执行流程

b41928b82274e49711330dadff0a9cd7.jpeg

Bootloader project 设置

1) Keil设置

图5. Bootloader project中address 1在Keil设置

1d66ed699c3ecf5720a4b62ebe3a7165.jpeg

2) Bootloader源程序修改ota.h文件中

图6. Bootloader project中address 2在程序中设置

22d143d271bb6f1e6c8ced8fea80d52d.jpeg

App project 设置

OTA demo提供了2个App程序供测试用,皆以address 2(0x800 4000)为起始地址。App1 LED3闪烁,App2 LED4闪烁。以App1为例,设计步骤如下:

1) Keil工程设置

图7. App project中address 2在Keil设置

29ff36c876961a590d5e8f1b533cb52c.jpeg

2) App1源程序设置

图8. App project向量表偏移在程序中设置

57f9eacd2322d3e19460aa4ca98a49da.jpeg

3) 编译生成bin文件

通过User选项卡,设置编译后调用fromelf.exe,根据.axf文件生成.bin文件,用于OTA更新。通过以上3个步骤,我们就可以得到一个.bin的APP程序,通过Bootloader程序即可实现更新。

4) 开启debug app code功能

如果在设计App code过程中需要对App project进行单独调试,请按照以下操作。

● 先下载Bootloader工程

● 再调试App工程

Dual app OTA与程序设置

地址分布

图9. Flash地址分配

f81684b922b43895b5f4a4fd78ba7619.jpeg

注:Bootloader区域最后2个扇区,用于存放App是否正常的flag,用户编译修改Bootloader时,要保证不覆盖flag的地址。

执行流程

OTA分为Bootloader、App1和App2三部分,应用在App1或App2中执行。程序执行整体流程框图如下:

图10. 程序执行流程

77e12a398a2368568e1ca8ec1740d608.jpeg

Bootloader project设置

3) Keil设置

图11. Bootloader project中address 1在Keil设置

185c7bad4dd2c715e729e0bc52b1328c.jpeg

4) Bootloader源程序修改ota.h文件中

图12. Bootloader project中address 2在程序中设置

0cfd89f4e548c48182cf4b28e593b581.jpeg

App project设置

OTA demo提供了2个App程序供测试用,app_led3_toggle以0x800 4000为起始地址,app_led4_toggle以0x8080000为起始地址。App1 LED3闪烁,App2 LED4闪烁。以App1为例,设计步骤如下:

5) Keil工程设置

图13. App project中address 2在Keil设置

96b92ae8689d3fc9529539f851b48c4b.jpeg

6) App1源程序设置

图14. App project向量表偏移在程序中设置

7d935f5ed7699925ad10d591dd3c4b1e.jpeg

7) 编译生成bin文件

通过User选项卡,设置编译后调用fromelf.exe,根据.axf文件生成.bin文件,用于OTA更新。通过以上3个步骤,我们就可以得到一个.bin的APP程序,通过Bootloader程序即可实现更新。

8) 开启debug App code功能

如果在设计App code过程中需要对App project进行单独调试,请按照以下操作。

● 先下载Bootloader工程

● 再调试App工程

Bootloader/App与上位机串口通信协议

程序与上位机通信,接收固件升级数据,上位机端和嵌入式端通信协议如下:

1) 上位机通信协议

图15. 上位机通信协议

5fb673fbb9f60f66c5d98536a1414755.png

2) 嵌入式端下位机通信协议

图16. 下位机通信协议

7352458622bcf023ce98e04930e30c0a.png

ACK0xCCDD

NACK0xEEFF

Data0x31+Addr+数据+chenksum(1byte)

Addr:4bytes,高位在前

Kbytes,下载数据,不足2K内容填充0xFF

Checksum:1byte,4bytes的Addr+2KBytes数据的校验和的低八位

------------ END ------------

b4cc6758d6af56fc631c88e9357dd4d4.gif

●专栏《嵌入式工具

●专栏《嵌入式开发》

●专栏《Keil教程》

●嵌入式专栏精选教程

关注公众号回复“加群”按规则加入技术交流群,回复“1024”查看更多内容。

efcf232a13bd29bafbbcbf96367a489d.jpeg

8412fe00d8babb21f902c0e21a8ce79c.png

点击“阅读原文”查看更多分享。

<think>好的,用户想了解MCUOTA升级方法和解决方案。首先,我需要回顾一下之前的对话。用户之前询问了T-BOX与车机娱乐系统的连接,现在转向MCUOTA升级,这可能与汽车电子系统或其他物联网设备的固件更新有关。 根据用户提供的引用资料,引用1到5提到了不同的OTA方案,包括差分升级、Boot升级、硬件复位机制、MCU重启问题以及标志位设置。用户需要综合这些信息,给出MCU OTA升级的具体方法和解决方案。 首先,要明确MCU OTA的基本概念。MCU通常资源有限,不像高性能处理器那样容易处理大文件,因此需要考虑节省带宽和存储空间的方案,比如差分升级。引用2提到艾拉比的整机级方案,使用差分算法减少下载时间,这可能适用于MCU。 接下来,需要考虑升级过程中的安全性。引用1提到版本校验,引用2和3强调了安全鉴权和回滚机制,这些都是关键点。另外,引用3提到硬件IO检测作为恢复机制,这对防止升级失败导致设备变砖很重要。 然后,硬件设计方面,引用4指出MCU重启时的供电问题,可能导致无法正常重启。需要设计独立的电源管理模块,或者软件上确保重启时维持供电。引用5提到在特定内存地址放置标志位,用于Bootloader判断升级状态,这也是常见的做法。 用户可能还关心具体的实现步骤,比如Bootloader设计、双区存储切换、断点续传等。需要将这些技术点组织成清晰的方案,并给出行业案例,比如家电或汽车中的应用,如引用2中的家电方案和引用1的OTA服务流程。 最后,要确保回答结构清晰,分点说明,涵盖基本原理、关键技术、安全设计、典型方案和行业案例。同时,生成的相关问题要引导用户深入探讨,比如安全性优化或资源受限下的解决方案。</think>### MCU OTA升级方法及解决方案深度解析 MCU(微控制器单元)的OTA(空中下载技术)升级是物联网设备固件更新的关键技术,其核心挑战在于资源受限环境下的可靠性、安全性和兼容性设计。以下结合行业实践与引用资料提供系统性解决方案: --- #### 一、MCU OTA基本原理 1. **技术架构** $$ \text{云端管理平台} \xrightarrow{\text{HTTPS/MQTT}} \text{MCU固件包} \xrightarrow{\text{差分/全量}} \text{设备端Bootloader} \xrightarrow{\text{双区切换}} \text{运行新固件} $$ 典型流程包含**版本检测→下载→校验→激活→回滚**五个阶段[^1]。 2. **核心组件** ```text - Bootloader:占用4-16KB Flash,实现固件校验、跳转(引用5) - 双存储分区:Active(运行区)与Backup(升级区) - 硬件看门狗:防止升级过程卡死(引用4) ``` --- #### 二、关键技术实现方案 1. **差分升级优化** - **算法选择**:针对Renesas等MCU优化BSDiff/XDelta算法,压缩率可达60%-90%(引用2) - **内存管理**:采用分块下载机制,示例代码: ```c #define BLOCK_SIZE 512 // 根据RAM容量调整 uint8_t ota_buffer[BLOCK_SIZE]; while (download_next_block(ota_buffer)) { flash_write(ota_buffer, current_address); current_address += BLOCK_SIZE; } ``` 2. **安全启动设计** - **数字签名**:使用ECDSA或RSA算法验证固件完整性 - **防回滚**:在Flash特定位置(如0x00000FF0)存储版本号(引用5) $$ \text{签名验证流程: } \sigma_{\text{新固件}} \stackrel{?}{=} \text{Verify}(PK_{\text{厂商}}, H(\text{Firmware})) $$ 3. **硬件辅助升级** - **强制恢复模式**:通过检测GPIO引脚电平(如长按按键3秒)触发出厂固件恢复(引用3) - **独立供电设计**:采用LDO+电容组合确保升级期间不掉电(引用4) --- #### 三、典型解决方案对比 | 方案类型 | 适用场景 | 优点 | 缺点 | |----------------|---------------------------|-------------------------------|-----------------------| | **双区切换** | 资源充足型MCU(>128KB Flash) | 升级失败可回滚,可靠性高 | 占用双倍存储空间 | | **原地升级** | 低资源MCU(<64KB Flash) | 节省Flash空间 | 需完整校验防止数据损坏| | **压缩差分** | 网络带宽受限环境 | 减少70%数据传输量(引用2) | 需额外RAM进行解压 | --- #### 四、行业实践案例 1. **家电领域** - **艾拉比方案**:通过组件化设计实现家电整机OTA,支持Homebus/CAN等多总线(引用2) ```mermaid graph TB 云平台--加密差分包-->WiFi模块--SPI-->主控MCU--CAN-->子设备MCU ``` 2. **汽车电子领域** - **双Bank升级**:在STM32中划分Bank1(运行区)与Bank2(升级区),通过FLASH_CR寄存器的SWAP位实现热切换[^1] - **安全回滚**:当CRC校验失败时,自动跳转至备份固件(引用3) --- #### 五、关键问题解决方案 1. **断电保护机制** - **断点续传**:在Flash中记录已下载块的位置索引 - **原子操作**:使用STM32的Flash编程锁防止写操作中断 2. **资源受限优化** - **混合升级模式**:小更新用全量升级(代码段<10KB),大更新用差分升级 - **内存复用**:复用通信缓冲区作为解压暂存区 --- ### 相关问题 1. 如何设计MCU OTA升级中的数字签名验证流程? 2. 在RAM不足的情况下如何实现差分升级包的解压? 3. 汽车电子领域的MCU OTA与消费电子领域有哪些特殊要求差异? [^1]: 实际工程中需根据MCU的Flash分页特性设计双区切换机制,例如STM32F4系列的Sector擦除规则。 [^2]: 家电领域OTA需考虑多设备协同升级,需实现主控MCU与子设备的分批升级调度。
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值