ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

PY32F系列MCU在OTA时App区概率性跑不起来的根因分析(1)

PY32F系列MCU在OTA时App区概率性跑不起来的根因分析(1) 一、问题现象1. 概述在项目中使用PY32F0和PY32F4系列的两款芯片。在OTA时会有概率性App无法正常跑起来。2. 详情细节描述如下压测OTA不断进行反复升级比如100次、500次、1000次。发现总体上会有10~20%的概率App不能正常跑起来。宏观现象上来看正常App跑起来的时候LED指示灯以一定间隔如2秒闪动亮灭。但实际看到的现象分为以下几种1程序陷卡在Boot区出不来通过串口发强制退出Boot区指令可以跳转到App区工作正常2程序陷卡在Boot区出不来通过串口发强制退出Boot区指令无响应。重启或者断电/上电后可以正常调转到App区3程序陷卡在Boot区出不来通过串口发强制退出Boot区指令无响应。重启或者断电/上电后仍在Boot区此时通过串口发强制退出Boot区指令可以跳转到App区工作正常4程序完全跑飞所有指示灯都不亮既不在Boot区、也不在App区5程序陷卡在Boot区出不来断电/上电一次不行第二次能够正常跳转到App区。二、问题分析1. 初步分析和所采取措施上边的问题很多相应地可怀疑之处也有很多。这就需要逐层、逐块、逐点进行排查。抽丝剥茧、层层递进。引发问题的原因可能有如下几个1串口数据接收过程中数据出现了错误导致烧录的数据是错误的由于使用的是串口RS485通信因此一开始认为数据比较可靠没有加入检验。后来在实测中发现数据偶然也会出现错误不够稳定。因此加上了校验机制当校验不通过时返回失败。这样就从源头确保了数据的正确性避免了由于数据本身错误而导致的跳转到App后运行异常。2数据没有问题烧录出现了问题烧录过程调用的是系统HAL库接口这方面理论上是比较可靠的。即使如此排查问题的过程中也对此有所担心专门加入了相应的指示灯一旦某一帧烧录出现错误指示灯就会给出提示。但实际测试下来指示灯从未出现过问题基本排除了Flash烧录方面的错误。3数据和烧录都没有问题读写EEPROM出现了问题这一块一开始并没有怀疑认为是可靠的。但实测中发现即使接收数据都正确烧录过程也无误最后设置标志位再读取是否写入成功结果发现读取的数据与写入的不一致从而根本就没有执行跳转函数。经过排查其实是EEPROM读取的应用程序写错了在函数中的局部变量没有清零下边又用到了该变量的或因此就出现了问题。volatile uint32_t ret; for (i 0; i len; i) { e2prom_buf_read(data, addr i, 1); ret | ((uint32_t)data (8 * (len - 1 - i))); }对ret进行初始化将其赋值为0问题解决。后续这一块没有再出现问题。4整个过程都没有问题跳转出现了问题将以上几个问题解决后原因就剩这一块了。但是这里又分为几个怀疑点1烧录后跳转到App出了问题2不经过烧录过程直接跳转到App就出问题3Boot或App自身存在问题。以上几个怀疑点优先排除2因为从来没有发生、发现过启动后直接跳转就跑飞的情况。其次排除3因为不进行OTA的话Boot和App配合是能够正常工作的。那么问题大概率出在了“1烧录后跳转到App出了问题”上。到底问题出在了哪里又该如何进一步排查呢请看下回。
返回列表