STM323程序升级的一些注意事项_配件

（1）CRC只是完整性.有效性,应该包含bin文件中,特定地址数据的判别.

（2）加个版本号判断，产品标准识别，然后再CRC校验。

（3）自定义文件格式，增加文件头，内置：硬件ID，程序版本，编译日期，等信息
负责升级的程序，先读取这些信息，再读取硬件已有程序的信息，再做决定如何做

自己加校验以及产品的型号,版本等

（4）8楼提到的文件头，可以在升级之后写到程序区最后一个扇区未尾，用于下次升级时比较板本号之类的操作。

（5）在升级文件的文件头(上传的第一包)里含有基本校验信息，如适用的设备型等信息，

如果不对就终止升级，当第一包的基本信息校验通过，才允许上传整个BIN文件，

当上传完毕后进行CRC校验，无误则升级成功，否则恢复还原升级前的版本，并上报升级失败等。。。

（6）

编译日期有不有自动加入的手法？请指教！
const char c_date[] __attribute__((at(0x08001000))) = __DATE__; //指定地址存放日期
const char c_time[] __attribute__((at(0x08002000))) = __TIME__; //指定地址存放时间

（7）

我的应用是这样的：
STM32内部FLASH分为:BOOT+APP1(主)+APP2(临时)+数据区(模拟EEPROM)
再请教下具体是不是这样做：主APP1和临时的APP2是一样的，或者说APP2就是APP1的备份。
升级过程中用新的APP去升级主APP1，如果检测到新的APP有问题就用APP2恢复到上一个版本，如果没有问题，把APP2也升级为最新的版本APP.
目前的确遇到FLASH不够用的问题，所以没法去备份一个临时的APP，因为我是使用SD升级的，所以在想是不是升级前用SD卡把旧的版本一次，所以发现新的有问题还能恢复过去。

这里我再提一个建议，最好有三份APP的空间
一份是用于升级暂存，另外两个为最新两个版本(注意，这两个版本都是可以正常正确的，可以正常运行的)
这样的好处于是，不管是升级文件上传是否正确都不会影响到升级前后两个版本的任意切换运行。
即：当升级文件上传失败时，也不会影响当前已经成功升级的最新两个版本，可以随意节换运行。

（8）

单片机做通讯，怎么实现数字签名？
消息签名和文件签名类似. 甚至预先烧个一样的key用来做hash也可以的

(9)

如何确保更新的APP是你需要的APP，而不是别的一个APP？

前面的问题保证了更新的程序是完整的，但是完整的程序不一定就是你需要的程序，那么怎么确定是你需要的APP呢

通过bin文件名来确定吗？这是一个方法，但是bin文件名可以被用户轻易更改，那就只能从bin文件内容本身入手了。

常规方法是，通过某些工具，在bin文件中加几个字节标着文件的特殊性，但是众所周知的是，鱼鹰比较懒，看似简单的只是加入几个字节的事情，如果产品成型的话比较好说，更新次数比较少，但是一旦产品处于测试阶段，更新频繁，累人不说，还可能出错。

那么有什么办法呢？就从代码本身入手好了。

方案确定下来了，但是怎么处理呢，标志位放在哪里，怎么放？又是一番苦思冥想。

一开始想到的是想将标志位放在bin文件最后，但是bin文件的大小是不固定的，虽然说上位机可以把bin文件大小传下来，但是怎么放是个问题，开始打算通过修改链接文件实现，但是发现自己对链接过程不熟，对汇编语言（汇编可以指定地址）也不熟，怎么办？

最终鱼鹰选择把程序标志放在向量表的后面，即通过指定变量地址的方式保证地址唯一性（需要注意一点的就是，通过指定地址的方式，不一定就确保最终的地址就是你设定的地址，如果和其它地址冲突了的话，可能不一致，需要看map文件确定）。而且在设置APP程序的时候，一般都会重新定义向量表的位置，那么可以在定义标志地址时利用这个地址进行偏移。

当BootLoader在写前面8个字节前，只要再判断这个地址的标志位是否正确即可。

到此，固件升级方面的知识应该比较完善了，但还有一个问题，如何对bin文件加密与解密呢？

这个问题只有下次项目需要的时候再研究了。

（10）