基于WiFi和云端的无线远程升级方案
关键词：OTA，IAP
方案目标
基于WiFi和云端完成无线远程对产品WiFi固件和MCU固件分别进行升级刷新，当产品售出后需要维护时，该方法具有较强实际意义。
总体方案
利用机智云云端OTA技术+产品主控MCU（STM32）的IAP功能来实现。
具体实现
1、WiFi固件升级
包含：添加固件、验证固件、添加规则、开始推送、推送完成。首先产品连上云端，在云端产品操作界面选择固件升级（OTA）——WiFi，添加固件（下载官方最新的，采用SOC方案可以自己更改固件内容），填好信息，然后进行固件验证，查询MAC后输入进行验证和推送直到成功刷新固件，然后产品会自动重连云端正常工作，用户端无需任何操作。若选择静默升级则自动进行全部过程，手动升级需要APP端点击确认。
注意：
1、该固件软件版本号要比目前产品WiFi固件版本号高才能升级；
2、推送固件过程中要保证网络稳定通畅，设备连接稳定，正常情况下推送还是挺快的。
2、MCU固件升级
云端OTA操作同1，选择固件升级（OTA）——MCU即可；
MCU（STM32）上采用IAP（在应用编程）方式实现功能。先通过板子上的boot引脚将其设置为IAP启动模式，然后进行程序上的修改，添加远程升级功能。
思路：将MCU(STM32)的flash分成四个区域,地址由小到大分别为:bootloader、flag、app、app_bak四个区域。(具体分区大小由板子flash大小决定)
bootloader:存储bootloader固件，MCU 上电后首先运行该固件。
flag:存储有关升级的相关标志位，bootloader和app分区都需要操作该区域。
app :存储用户程序固件。
app_bak :临时存储云端下发的新固件，升级固件的一个过渡存储区。
按思路，编写bootloader和app两部分工程程序.
bootloader 的主要职能是在有升级任务(无升级任务时运行目前app区域里的程序)的时候将app_bak 分区里面的固件拷贝到 app 区域.这期间需要做很多工作，比如升级失败的容错等等。需要注意的是，在校验 MD5 正确后开始搬运固件数据期间，MCU 出现故障（包括突然断电），MCU 应发生复位操作（flag区域数据未破坏），复位后重新开始执行 bootloader，从而避免 MCU 刷成板砖。
bootloader工程配置，需要配置好下载到flash哪部分区域，（和预先分配的分区|程序里写的一致）要使flash烧写有效，然后使用link（J|STlink）先将bootloader部分烧写到MCU里。
app部分,在要添加远程升级功能的工程程序里，添加接收云端新固件功能的部分程序即可。具体需要添加flash区域配置、MD5校验、OTA功能代码（在原product、protocol相关文件里添加OTA有关代码）等。
注意:
1、STM32中断向量地址偏移默认0x00,需要根据app实际分配地址进行修改，否则bootloader运行后无法跳转到实际的app处运行主体程序；
2、实际分区以及数据、环形缓冲区等的大小，要根据固件(bin文件)和MCU的flash实际大小进行合理分配。
app工程配置，同bootloader,配置好实际下载的flash区域，同时通过配置生成bin文件，然后通过link把app部分程序也烧录到MCU里。重启MCU可以看到程序正常运行。
接下来更改app部分程序，生成最新的bin文件，上传到云端进行OTA，更新后产品端同样自动重连云端正常工作，执行更新后的功能程序，即实现了远程升级。（OTA过程注意事项同WiFi固件升级）
验证结果
1、 按上述方案编写bootloader和app工程并生成可执行文件;
2、 将bootloader和app的可执行文件烧录到MCU中；
3、 仅用移动电源对MCU(及WiFi)进行供电，即与PC机无任何有线连接，通过上述方案进行无线远程升级，可以通过云端或移动端APP监察到WiFi固件和MCU固件版本号发生更新改变，观察到产品具体功能改变（改进），说明升级成功。