bootloader拷贝升级的检测方式

中断向量表里有几个预留的空间足够你存大小了， 且位置也在固件的固定位置

无法知道当前app的实际大小

那就把当前app信息存起来呗。也就是把rbl头给存起来。

用download分区新固件的大小计算当前app分区crc值就行了吧

gcc和keil我都做过在固定位置存储一段信息，可以保存自身的程序大小等信息。keil好做些，gcc要修改ld文件，添加一些段实现，这样boot接收到app固件后，从前面多少个字节后直接读取就能读到app的相关信息。

当前app的实际大小可以编译进代码，存放（__at())在一个约定的地址；
我就用这种方法让boot获取app版本信息等

CRC32只适用于一般完整性校验，不适合作为版本迭代依据。对于常规手段来说，头里面加点信息就好了。如果对于bin文件做深度加工，满足安全加密需求，选用Block形式的存储方式，例如UF2,我觉得是比较优雅的。

在APP程序里面通过（__at()) 关键字预留好crc32和app_size的空间， IDE编译出BIN之后通过python工具计算整个二进制文件的crc，读取大小之后修改BIN文件生成升级包。感觉只能这样了。

可以考虑把 download区 再分成2部分：

1. 前部分叫 bin文件信息区，用来存储 bin文件大小、crc32、固件版本号等信息。其空间大小最好是 存储介质（如flash）最小写单位的整数倍，以保证 写bin文件信息区 时不会破坏 bin文件内容区 内容。
2. 后部分叫 bin文件内容区，用来存储 bin文件内容。
   app程序逻辑可以这样写：
3. 全擦除 bin文件信息区 和 bin文件内容区。
4. 将固件下载存储到 bin文件内容区，并检验 下载存储内容的正确性。
5. 确认正确后，再写 bin文件信息区，以标志下次重启后要执行 升级操作。
6. 然后 触发重启。
   bootloader程序逻辑可以这样写：
7. boot启动时，检查 bin文件信息区 内容是否为全0xFF（其实如果 bin文件大小 是放在最前面，那只检查 其是否为 全0xFF 即可）。
8. 如果 非全0xFF，则直接启动 app；否则 执行升级操作。
9. 升级完成后，至少擦除bin文件信息区(擦除后内容为全0xFF)，也就是 破坏 bin文件信息区，保证 下次重启 不会再执行 升级操作。

将升级的文件信息全部封装到文件头