在技术支持群,看到有用户报了一个不明原因的重启问题。 重启现象是 ——有极个别设备在工作中不定时反复异常重启,大部分设备正常;反复重启设备,有时候又能持续正常工作。
隔着屏幕都感觉到了客户的着急和无奈,我决定和这位用户一起揪出这个“捣蛋鬼”。
一、查找线索
按常规流程先询问用户开发模块、开发方式,并要求提供对应日志。经确认如下:
开发模块:Air780E
最新资料:www.air780e.cn
开发方式:LuatOS
开发教程:
https://doc.openluat.com/wiki/26?wiki_page_id=3020
客户提供日志反馈:
脚本日志没报错误,就是不定时卡住一会,然后就重启了。
第一反应:不会是死循环导致的重启吧?
用户反馈:“没有死循环,任务里面都有延时的,而且大部分设备是正常的。且重启的时间也不定,最短4秒,最长是三分多钟,看起来不符合20秒的看门狗重启呀,而且设备昨天有正常工作一天,然后异常的时候就持续一直异常。但是这个固件的绝大部分设备是正常工作,不会异常重启的。”
看来不是死循环导致的看门狗重启问题。
为了进行一步排查重启原因,我让用户用pm.lastReson()这个接口打印开机原因值。
客户反馈:“我们有平台上传数据, pm.lastReson()是006异常重启 ”。
根据接口文档相关说明来看,确实不是内部看门狗导致的重启,是异常重启导致的。
接口文档详见:
https://wiki.luatos.com/api/pm.html#pm-lastreson
二、了解背景
心想看不出啥具体原因,先了解一下客户使用背景吧,说不定会有啥线索。
我问:“之前正常,现在是用不了,一直在重启吗?”
客户反馈:“也不是吧,一开始是好的,然后挂了几个月一直重启,最近发现,昨天我拿过来挂了一天又正常,然后今天又重启,老化区就这个设备会重启,其他同固件是正常的。”
我又问:“换DEMO会重启吗? 确认一下是硬件问题,还是软件问题。 ”
客户反馈:“ 今天测试过,只下载脚本是一定会出问题。 然后我刚刚重新下载底层和脚本,目前五分钟没有重启。”
看上去应该不是硬件问题,可能是软件引起的。心想让客户用最新版本试一下吧,确认一下还会不会出现问题。
客户反馈:“我们是因为有一个设备到客户手上有这个问题是V1108的,然后老化区只有这个设备也是异常重启,是V1106的,然后就看的这个,后面重新烧录1106的底层也是正常的,这设备挺难出现这个问题的,只能我们这边挂着测一下。”
看来又是一个令人头大的重启问题,要等客户提供底层日志来进一步排除问题了。
三、重要线索
客户把挂测的底层日志提供过来了,打开后确实看到了RamDumpData开头的死机信息。
打开上面的RamDumpData出现如下信息:
我赶紧和研发大佬确认,可能是啥情况。大佬问答大概率是FLASH坏掉了,让和客户确认不是有KV相关的操作。
客户回答,确实有KV的操作。
本文提到的KV:
KV数据库 ——指的是LuatOS中的FSKV库,提供键值对数据库功能,数据持久化在Flash上,使用独立的KV分区,使用LuaTools刷机时可选择清空,默认是不清空。由Flash的特性决定了,写入次数是有限的,频繁写入导致超限后,将无法设置/更新数据,导致系统异常。
为了进一步验证猜测,让客户做了如下测试:
问:“死机重启后,烧录不清除KV试试看还会不会重启,或者去除KV相关操作看还会不会重启。”
答:“KV操作挺多的,不好清除,我试下烧录不清除KV,有时候断电过一会就好了,不是很好复现,我先试试烧录不清除KV。”
客户反馈:“不清除KV也会有重启。”
问:“重新烧录底层的时候,有没有清理KV。”
答:“有”…
根据此前客户反馈和当前测试来看,应该是FALSH模块有些区域坏掉了。
四、确认猜测
至此,可以说这个重启的原因基本是确认了,导致模块令人琢磨不透的重启问题的“捣蛋鬼”也基础上算是给揪出来了。但是,还是需做进一步的测试来确定猜测。
研发大佬给了一下测试固件,来确认猜测是否正确。
经过测试验证后,确定是FALSH部分区域坏掉引起的重启。
至此这个“重启案件”算是侦破了。
给客户的建议:
要改脚本,需要大幅度减少写KV的次数,防止破坏模块重启的“捣蛋鬼”再次出来捣乱。
温馨提示:
KV的写寿命是10万次,过于频繁操作可能会导致FLASH坏掉,引起设备反复重启。
因此,在写代码的时候要尽量减少写KV的次数。
审核编辑 黄宇
-
接口
+关注
关注
33文章
8574浏览量
151007 -
烧录
+关注
关注
8文章
259浏览量
35561 -
LuatOS
+关注
关注
0文章
76浏览量
1936
发布评论请先 登录
相关推荐
评论