【CH579M-R1】+节约FLASH的OTA方式（方式二）

Ansersion 发表于 2021-1-24 23:29

<div class='showpostmsg'>概述

之前我们讨论过AB面的OTA方式，其最大的优势就是：即使升级失败，旧版依然可以运行，相应的缺点就是会大量占用FLASH。本文讨论的OTA方式二正好与AB面OTA方式相对，其虽然不能同时保留两份程序备份，但是它可以很大程度上节省FLASH。

<h1 style="margin-top:22px; margin-bottom:22px; text-align:justify">FLASH结构</h1>

OTA方式二的FLASH结构如下，



最前面的是Peripheral程序，也就是用户业务逻辑程序，此处我们分配了150K。Peripheral程序是可以升级的。

紧跟着的是OTA程序，当设备进入OTA程序时，就进入了等待升级状态。OTA程序是不可升级的。

最后是BLE STACK LIB，这部分占用空间最大（约250K），可以由Peripheral程序和OTA程序共同调用。这种OTA方式之所以节省Flash，原因就在于此，因为该种方式只有一份BLE STACK LIB的备份，而不像AB面OTA方式有2份。BLE STACK LIB是不可升级的。

<h1 style="margin-top:22px; margin-bottom:22px; text-align:justify">OTA流程</h1>

当设备启动时，设备会运行最开始的Peripheral程序。当Peripheral程序接受到升级触发条件后，就会跳转到OTA程序。此时我们就可以使用官方提供的APP进行升级了。

<h1 style="margin-top:22px; margin-bottom:22px; text-align:justify">实操</h1>

现在我们需要打包一个初始升级包（打包工具见附件），将Peripheral、OTA和BLE STACK LIB打包到一起，然后通过电脑升级。

首先，如下图所示，我们来编译Peripheral程序和OTA程序。

其中Peripheral占用前125K的Flash，OTA占用接下来8K（0x2000）的FLASH。他们共同使用从0x20006000起8K（0x2000）的RAM（0x20006000之前的RAM被分配给了BLE STACK LIB）。



编译完成后，我们通过打包工具依次将以下3个文件打包

EVT\EXAM\BLE\PERIPHERAL_ONLYUPDATEAPP\PROJECT\OBJ\BLE.HEX

EVT\EXAM\BLE\OTA_ONLYUPDATEAPP\PROJECT\IMAGEOTA\OBJ\IMAGEOTA.HEX

EVT\EXAM\BLE\LIB\CH579BLE_ROM.HEX



然后我们将打包好的文件（此处为“OTA2.bin”）通过ISP软件烧录进CH579M



烧录完成后，Peripheral程序就可以正常运行了。如前所述，如果进行OTA升级，必须让设备运行OTA程序。通过Peripheral的代码，我们看到GotoResetVector()为跳转OTA程序的函数，要触发该函数必须往Peripheral的0xFFE1特征值写数据，此处我们使用NRF-CONNECT蓝牙调试工具写入一个任意字节。



这时设备会进入OTA程序，此时我们会发现设备的广播名称变成了“OTA OTA OTA OTA！”



现在，我们就可以用之前AB面OTA方式一样的流程去升级程序了，注意新程序的要在Peripheral_OnlyUpdateApp例程基础上改写，并且必须放到手机APP的ImageA的目录里。

具体参见：https://bbs.eeworld.com.cn/thread-1154663-1-1.html

至此，方式二的OTA升级方式就完成了。

 

繁絮至此，但求明细。

 

attach://522845.exe
</div><script> var loginstr = '<div class="locked">查看本帖全部内容，请<a href="javascript:;" style="color:#e60000" class="loginf">登录</a>或者<a href="https://bbs.eeworld.com.cn/member.php?mod=register_eeworld.php&action=wechat" style="color:#e60000" target="_blank">注册</a></div>';

if(parseInt(discuz_uid)==0){
(function($){
var postHeight = getTextHeight(400);
$(".showpostmsg").html($(".showpostmsg").html());
$(".showpostmsg").after(loginstr);
$(".showpostmsg").css({height:postHeight,overflow:"hidden"});
})(jQuery);
} </script><script type="text/javascript">(function(d,c){var a=d.createElement("script"),m=d.getElementsByTagName("script"),eewurl="//counter.eeworld.com.cn/pv/count/";a.src=eewurl+c;m.parentNode.insertBefore(a,m)})(document,523)</script>

chenguo1982515 发表于 2021-1-25 09:06

好。

swimming-fang 发表于 2021-1-25 17:07

chenguo1982515 发表于 2021-1-25 09:06
好。

再次谢谢楼主！<img height="73" src="https://bbs.eeworld.com.cn/static/editor/plugins/hkemoji/sticker/facebook/wanwan42.gif" width="82" />

w494143467 发表于 2021-1-26 21:44

内存够的时候用方式一，内存不够的时候用方式二，可以直接进行判断！！！这样好！！！

水上的浮尘 发表于 2021-3-25 16:12

请教楼主，当App跳转到Bootloader的时候，怎么重设置中断向量的呢？？

Ansersion 发表于 2021-3-25 22:24

水上的浮尘发表于 2021-3-25 16:12
请教楼主，当App跳转到Bootloader的时候，怎么重设置中断向量的呢？？

BootLoader是芯片内置的，我们改不了的。我想你说的Bootloader是指“OTA”吧。

一般编译器会在一个完整程序的main函数前加一段起始代码，这段起始代码工作之一就是重置向量表。

如下图蓝框所示，只要你运行0x24800的第一行代码（确切来说是0x24800+4，第一个4字节是堆栈地址，第二个4字节才是Reset函数入口）就会进入OTA的起始代码逻辑，他自己会重置向量表的。

水上的浮尘 发表于 2021-3-28 15:14

Ansersion 发表于 2021-3-25 22:24
BootLoader是芯片内置的，我们改不了的。我想你说的Bootloader是指“OTA”吧。

一般编译器 ...

我仔细研究了一下代码，发现是这样的，OTA里只用到了蓝牙的LLE_IRQHandler，而APP里也有这个中断，LLE_IRQHandler这个中断应该是只为BLE库服务的，当APP跳转到OTA的时候，由于APP的这个中断还在，所以实际触发的还是APP里的这个中断地址，所以OTA即使不更改中断向量表也能正常工作（经测试，即使将OTA里的LLE_IRQHandler注释，也能正常工作），但是一旦要擦除APP了，就先把OTA的中断向量表（前512字节）拷贝到0地址，否则OTA就不能再继续正常工作了。

Ansersion 发表于 2021-3-28 23:29

水上的浮尘发表于 2021-3-28 15:14
我仔细研究了一下代码，发现是这样的，OTA里只用到了蓝牙的LLE_IRQHandler，而APP里也有这个中断，LLE_IR ...

这块是我想当然了，你的分析是对的，多谢指正！

 



我看了一下OTA的RESET中断，他调用了一下SystemInit之后就进入main了，而SystemInit里也没有重置中断向量表。

 

通过分析OTA的升级代码，发现了他确实把程序“第一块”内容（中断向量表）单独放入RAM缓存了，最后在编程结束时写入flash，而“其他块”则直接写入flash。

水上的浮尘 发表于 2021-3-29 09:07

Ansersion 发表于 2021-3-28 23:29
这块是我想当然了，你的分析是对的，多谢指正！

 

我看了一下OTA的RESET中断，他调用了一 ...

想问一下，CH579，我测试了BLE库的v1.4（此版本去年官方提供）和v1.7版本（目前官网下载的最新版本），发现2个速度完全不一样，同份代码，同样参数，采用官方提供的BLE调试注手，同样的下发方式，v1.4的速度快的多，具体在此帖子里

<a href="http://www.wch.cn/bbs/thread-71927-1.html">CH579芯片BLE库v1.4和BLE库v1.7速度测试比较问题 - 沁恒微电子社区 (wch.cn)</a>

这是什么问题啊？？

Ansersion 发表于 2021-3-29 23:15

水上的浮尘发表于 2021-3-29 09:07
想问一下，CH579，我测试了BLE库的v1.4（此版本去年官方提供）和v1.7版本（目前官网下载的最新版本），发 ...

因为这块BLE库的代码是闭源的，所以我也不是很清楚，不过就像这个论坛的朋友说的，可以改变那几个参数试试。

比对一下1.4和1.7的config.h，发现BLE_BUFF_NUM从“10”改成了“5”，多半是1.7的库占用了更多的RAM资源，所以官方不得已改变了这个参数。

水上的浮尘 发表于 2021-3-30 08:58

Ansersion 发表于 2021-3-29 23:15
因为这块BLE库的代码是闭源的，所以我也不是很清楚，不过就像这个论坛的朋友说的，可以改变那几个参数试 ...

我按照帖子里的参数试过，无效的

Ansersion 发表于 2021-3-30 17:13

水上的浮尘发表于 2021-3-30 08:58
我按照帖子里的参数试过，无效的

BLE库是官方闭源的，确实不容易解。

你提的这个问题很有启发性的，期待你能找到答案，还请不要忘记分享一下呀<img height="48" src="https://bbs.eeworld.com.cn/static/editor/plugins/hkemoji/sticker/facebook/congra.gif" width="48" />

水上的浮尘 发表于 2021-4-1 10:15

Ansersion 发表于 2021-3-30 17:13
BLE库是官方闭源的，确实不容易解。

你提的这个问题很有启发性的，期待你能找到答案，还请不要忘记分 ...

参数修改为BufMaxLen=251，BufNumber=0x04，TxNumEvent=0x04，有效

程英茂 发表于 2024-10-4 11:08

大佬们，这是什么原因，怎么解决？

页: [1]

电子工程世界-论坛's Archiver

【CH579M-R1】+节约FLASH的OTA方式（方式二）