一、需求：

因客户需求，觉得升级单片机程序需要打开设备的盖子，（抽出设备，拧螺丝，挺费事的）。

那能不能把单片机也做到linux系统下升级呢？

答案当然是可行的。（这里有个前提，单片机与rk3399的cpu肯定要有通信的通道，目前我这边有两块单片机，一块是使用了串口，一块使用了是iic，暂时没有其他通道调试）。

既然单片机能够通过串口升级，那把串口改到rk3399端，那肯定问题也不是很大。那就顺着这个思路开展活动。

二、展望

既然能够在rk3399的linux命令下升级，那完成服务器的远程升级也不是问题了，所以对于批量的单片机升级还是有一定的优势的。前提是在网络中。

这个也是我后面想做的一个事情。还在进行中。

三、对于从3399的升级，我的几点考虑

3.1 应该还是可以使用ymodem协议，现在随便都能找到ymodem的源码，所以这里可以省点力气。还是参考之前的串口升级功能吧。

3.2 尽量考虑升级失败的处理问题。

3.2.1 比如升级过程中中断

3.2.2 下载的文件不是对应的bin文件

3.2.3 下载的时候，数据错误。

3.2.4 相同版本是否需要升级？

3.2.5 升级失败后有什么补救办法？

四、根据上述几个问题，我把升级程序做了几个事情。

4.1 为了防止重复升级，增加了md5的检测工作

4.1.1 升级的时候需要跟单片机通信，让单片机发送回当前镜像的md5值，这个值保存在flash的一个位置上。md5与现在的文件的md5相同，则不继续升级，否则的话才可以继续升级。

4.1.2 同时，修改ymodem协议，ymodem第一帧会发送文件名和长度，在这个后面增加一段md5码的ascii形式，单片机收到文件名和长度后，继续解析md5值，并且与自身的md5值（保存在flash上了）进行比较，发现如果相同，则终止接收数据，结束升级。

4.2 为了防止升级过程中，保存了错误的数据。

4.2.1 下载的过程中，每一个数据帧进行crc16的校验，下载后，比对校验值，正常才进行写到flash中，否则丢弃，重新下载

4.2.2  下载完成后，全部的数据进行一次md5计算，与之前文件名后传进的md5值进行比较，一致才认为可以进行下一步升级。

4.2.3  升级过程分为下载和升级，flash分成两个区，一个是下载区，用于串口下载程序，另一个才是系统程序的运行区，这个地方跑单片机程序，所以下载的时候，首先擦除的区域是下载区，并且把数据下载到下载区，下载完后，在下载区进行数据md5计算，正确之后，才会把数据拷贝到实际单片机app运行的区域（见4.2.2）。

4.3 为了防止下载其他文件（非单片机程序文件），导致错误。

4.3.1 第一就是升级程序本身是要验证下载文件的开始的位置，前4个字节是栈空间，它的值应该是在0x2000，0000这个区间，第4-7这4个字节是程序运行的位置，进行判断是否是与app的运行位置有关，只有通过验证，才能证明该文件是一个正常的单片机程序，才能允许下载操作。

4.3.2 单片机本身也要进行这两个部分的识别工作，在下载接收到第一个数据帧的时候进行帧头的8个字节的判断，下载结束后，md5验证正常后，拷贝到app区间之前，仍然进行头这8个字节的验证工作，正常，才进行拷贝升级。

4.3.3 下载文件必须有一个对应的md5文件一起，开始下载的时候，读取下载文件，并且同步读取md5文件中的md5值，计算下载文件的md5值，与md5文件中的值进行比较，正常才能进行下一步下载。否则不进行下载。

4.3.4  下载文件和md5文件由命令自动完成，单片机编译结束后，自动运行该命令，完成md5文件的生成工作，该md5文件不能由下载文件简单计算得出。

4.4 其他的一些防错机制

4.4.1 在iap阶段，可以进入下载模式自动下载。

4.4.2 在iap阶段，等待上位机下载（数据）的时间会有一个超时时间，长时间没有数据，将超时，重新回到待下载的状态，随时进入下一次下载更新状态。

4.4.3 要尽量确保iap的稳定，健壮，这一段程序一般情况下不能升级。

五、代码，请移步github

 

后面将对代码中的一些部分挑出来进行一些分析，欢迎大家关注和批评指正。谢谢