关于DA14580自定义OTA的方法

• 简介 

  　　  由于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.

　　

 

　　基本流程就是这样。

　　写到这里，就足够我自己忘记的时候拿出来看了。

　　若有需要，到时再补充一份详细版本。