分享一种IAP的思路

只看该作者 · 2013-12-11 14:41

该架构已经在产品中使用，并且在STM32，MSP430，STM8三款单片机都做过实际产品；
初步思路
1、把系统分为四个区域，BOOT区，APP区，APP BACKUP区，和PARAMETER(参数区)；
2、程序开始运行BOOT代码，然后跳转到APP代码中；
3、APP代码中收到触发升级命令之后跳转到BOOT代码中升级，BOOT代码下载程序到APP BACKUP中，如果升级成功，并通过校验，则把备份区代码拷贝到APP区，执行新程序；
4、如果多次升级失败，则停止升级，继续执行原有程序；

优点：
程序升级失败，不会对设备照成毁灭性的打击，仍然能自动恢复正常，无需人工干预；
缺点：
浪费FLASH空间；
建议使用领域：
远程升级；

只看该作者 · 2013-12-11 16:43

感谢楼主分享，缺点的第一项很关键，当时我做IAP的时候就考虑类似的结构，后来因为FLASH空间实在是不足，我们公司的产品对于flash的利用大多都是饱和，后来放弃了。

PS：
1，我并不觉得在FLASH里面建两个APP区有什么特别的好处，只要植入直接特殊的标志位（我当时利用MSP430的信息段flash和STM32的选项字节），即使是第一遍升级失败，第二次同样可以升级，直到升级成功，版本号++就可以。
2，我觉得在APP当中植入进入BOOT命令看似智能，操作性一般，我还是比较支持整机复位进入BOOT。

我并无驳斥楼主之义，程序的设计要根据产品的定位。楼主公司的产品如果是远离人操控，这方法很好，而我们公司的产品全部都是人直接操控的，而且与人直接接触，所以不太需要智能升级。

1万 · 2013-12-11 21:11

有点浪费。。。。。

只看该作者 · 2013-12-11 21:37

这种方法有利也有弊，但也值得参考。谢谢分享！

只看该作者 · 2013-12-12 08:31

副BAN主就是我发表于 2013-12-11 16:43
感谢楼主分享，缺点的第一项很关键，当时我做IAP的时候就考虑类似的结构，后来因为FLASH空间实在是不足，我 ...

呵呵，亲，你说话好客气，其实反驳是好事，我没这么小气的；
是这样的，我们公司有款设备用GPRS升级，每个服务器下数量在千到万之间吧，希望同时完成升级，因为网络信号原因，总有一些会升级失败，升级失败之后，有两个选择：
1.继续反复升级，直到成功；
2.升级多次（假定10次以后），失败就放弃升级，继续执行以前的程序；
做如上分区就是为了能在升级失败时候也能正常恢复程序，而不是下载成砖头了；
总之，我的意见，优点缺点都很明显，没有好与不好，只有适合与不适合；
另外，有想法尽管提，别骂人，其他都OK了，希共同交流；

只看该作者 · 2013-12-12 08:33

副BAN主就是我发表于 2013-12-11 16:43
感谢楼主分享，缺点的第一项很关键，当时我做IAP的时候就考虑类似的结构，后来因为FLASH空间实在是不足，我 ...

PS：我们升级都是在晚上，一旦到白天，客户就不让升级了，需要恢复工作；

只看该作者 · 2013-12-12 08:33

hithms 发表于 2013-12-11 21:37
这种方法有利也有弊，但也值得参考。谢谢分享！

Signature怎么设置的？？

只看该作者 · 2013-12-12 08:59

继续学习中

只看该作者 · 2013-12-12 09:10

Nick_Qiu 发表于 2013-12-12 08:33
PS：我们升级都是在晚上，一旦到白天，客户就不让升级了，需要恢复工作； ...

握手，共同学习！

只看该作者 · 2013-12-12 09:11

我也是这种思想，有利有弊吧。主要就是Flash空间

只看该作者 · 2013-12-12 09:13

请问，能否分享一下你的源码了，思路我也和你差不多，不知道是否方便，向你学习一下。

只看该作者 · 2013-12-12 09:15

如果在升级的过程中，也就是从APPBACK把代码拷贝到APP的过程中，突然断电，那岂不是就不能升级了，因为原APP已经被破坏了。

只看该作者 · 2013-12-12 10:12

hxb20122012 发表于 2013-12-12 09:13
请问，能否分享一下你的源码了，思路我也和你差不多，不知道是否方便，向你学习一下。 ...

抱歉当前无现成源码，因为源码都是产品上的，不能分享，不过直到思路，你花点时间，一到两天就OK了；

只看该作者 · 2013-12-12 10:19

hxb20122012 发表于 2013-12-12 09:15
如果在升级的过程中，也就是从APPBACK把代码拷贝到APP的过程中，突然断电，那岂不是就不能升级了，因为原AP ...

是的，在某些应用存在这种问题；
我当前的应用一般不会出现，我们是电池供电，现在我在程序上把电压分成三个状态，电量充足，电量正常，电量低，如果低电压在充足状态才允许升级，电池一般不会出现电量充足突然到电量低；
在其他应用上面，这个是个概率事件了；不过相信这概率也是比较小的，因为拷贝这段时间很短；
大家根据自己的应用，具体分析适合或者不适合；
很好，感谢交流；

只看该作者 · 2013-12-12 11:18

"................如果升级成功，并通过校验，则把备份区代码拷贝到APP区，执行新程序；"

这个功能是多余的，如果升级成功，并通过校验后，为什么要拷到APP区呢，在从App Backup拷贝到 App区还是有危险的，为什么不搞成两个区：APP1、App呢？当前代码在App1，新的代码升级到App2，然后就在App2区运行。

下次升级时，升级到App1，在App1运行，这样可以保证升级不成功，老的的那个程序是OK的。

只看该作者 · 2013-12-12 13:38

拷贝是有必要，如果程序跑飞了，那是该执行哪段程序呢？

只看该作者 · 2013-12-12 15:05

确实，由于Bootloader地位特殊，对它的可靠性要求相当高。即便出错，也必须能自行恢复。有的时候，这不仅仅是软件的事，硬件上必须提供必要的资源（比如足够的存储空间，高可靠的闪存架构等）

只看该作者 · 2013-12-13 08:49

江南依旧发表于 2013-12-12 13:38
拷贝是有必要，如果程序跑飞了，那是该执行哪段程序呢？

呵呵，看门狗；

只看该作者 · 2013-12-13 09:10

本帖最后由 Nick_Qiu 于 2013-12-13 09:12 编辑

金融小数发表于 2013-12-12 11:18
"................如果升级成功，并通过校验，则把备份区代码拷贝到APP区，执行新程序；"

这个功能是多余 ...

最初，我们也是想用这种方案，最终发现一些问题；
就是，这样APP1，和APP2，需要不同的分区设置，那么这样每次发布文件就需要发布给生产部门（生产初始化）和市场部门（更新维护）三个文件了，一个最初的下载文件，一个APP1的升级文件，一个APP2的升级文件；
首先他们就必须去区分，当前哪个该升级APP1，哪个该升级APP2了，生产和市场部门的人技术水平有限，如果搞错，那就是大面积错误了，想想，如果都从远端成功下载程序了，且验证了当前电压时充足的，总不会大面积出错吧；
其次是当初这个方案最初应用时在MSP430中，MSP430的中断不支持向STM32那种动态映射；换句话说，到APP1，和APP2中响应的中断地址不同。我尝试在某个地址中置个标志，然后中断函数中查询这个标志代表是APP1或者APP2，然后跳转到对于的映射区，实际标志正常了，跳转返回老是异常，我想可能是堆栈处理有问题吧；
最后，还有一个问题，我实际用这个设备，属于一个通讯基站，实际结构还有分区，另外有分区存储着传感器节点的程序；而一个基站的传感器节点是有十多个，如果按APP1 APP2这样的分区去处理，该基站下面的程序就有可能有些就是APP1有些是APP2了，存储翻倍了，还得想一系列的方法去管理；
总之，拷贝这个动作却是存在风险，不过当前我的应用时电池供电，如果是升级之前检查了电压没有低电压，程序在这一块又无BUG的情况下，风险应该是很小的；而两个APP区的方式，对我们首先会带来一系列的业务管理问题，而且当前还没实现；所以就做了一下取舍。选用该方案了。
我想想，这方案在STM32 上实现应该没事很么难度，小数如果在430或者STM8上实现了，还请赐教如何实现的。

只看该作者 · 2013-12-13 09:10

江南依旧发表于 2013-12-12 13:38
拷贝是有必要，如果程序跑飞了，那是该执行哪段程序呢？

看错老！！

分享一种IAP的思路

技术新星奖章

技术高手奖章

伴坛终老

甘甜之泉水

希望之星奖章

技术奇才奖章

奔腾之江水

七世轮回

精英会员奖章

涓涓之细流

缘定三生

以坛为家

欢快之小溪

社区建设奖章

突出贡献奖章

沉静之湖泊