转载自：https://www.cnblogs.com/asam/p/8676671.html
简介
由于DA14580的空间十分有限，可执行的代码空间只有32k。而官方自带的服务的代码量又十分多，基本一个服务要四个文件，2-4K的大小。因此很受限制。
本人在开发过程中，本身已经把代码空间用得差不多了，近29k大小，这时又要求加入OTA的功能，这时如果添加官方自带的SUOTA服务已经不够了。
另外又去查看了一下小米手环2里DA14580的服务，发现其也没有官方的OTA服务。即自己撰写了一个OTA的功能。
故而说明，自定义OTA的可行性。
基本原理
OTA（on the air），即空中烧录固件，固件的信息通过蓝牙传输的模式，把数据记录下来。
所以基本所有芯片OTA的思路都是，芯片的FLASH会划分为两个区，代码1区和代码2区，当程序运行了代码1区时，则将OTA的固件烧录在flash的代码2区（这个过程其实就是数据写入flash的过程），当烧录完成后，校验没问题后，再重启芯片，让DA14580从代码2区拿程序。
那么主要问题就有两个。
1.如何让DA14580主动去拿最新的那个固件程序呢？
2.烧录完之后程序如何重启呢？
其实重点在于第一个问题。第二个问题只是一句代码的事情而已。
DA14580的OTA分区情况
这个分区不是我定的，而是DA14580官方OTA服务本身就是这么定义的，总共又四个部分，1是secondbootload,2是分区1的引导文件和代码，3是分区2的引导文件和代码，4是总体引导代码。
secondbootload官方有提供，一小段代码而已。具体流程如下：
1 . 程序一开始是从secondbootload运行的，其首先会去flash的0x1f000这个地方拿信息。即在product_head拿信息，product_head里面记录了 img1head和img2head的地址。
2. 这时候拿到了img1和img2的地址了，这时候从这个地址里拿出 img1_head进行校验，校验比如 这个文件是否有效，CRC32是否正确等，以及固件id号是多少。然后再去拿img2_head的信息区进行校验。
3. 然后呢，假设两个代码区的这个引导信息，比如代码区2的引导信息检测到是无效文件，那么程序就执行代码区1的。如果两个代码区都是有效的文件，那么就会比较id号最大的是哪个，直接获取最大的那一个的代码。
4. 这就完成了整个OTA的流程。 我们在OTA的文件必然是 一个 包含了 img_head 和 img_code的固件，烧录完后修改img_head的id号，再最近的ID号里加1.