纯分享：合宙模组异常重启问题可以这样解决！

在技术支持群，看到用户报了一个不明原因的重启问题。重启现象是——有极个别设备在工作中不定时反复异常重启，大部分设备正常；反复重启设备，有时候又能持续正常工作。

隔着屏幕都感觉到了用户的着急和无奈，我决定和用户一起揪出这个“捣蛋鬼”。

一、查找线索

按常规流程先询问用户开发模块、开发方式，并要求提供对应日志。经确认如下：

开发模块：Air780E
最新资料

开发方式：LuatOS
开发教程

用户提供日志反馈：

脚本日志没报错误，就是不定时卡住一会，然后就重启了。

第一反应：不会是死循环导致的重启吧？

用户反馈：“没有死循环，任务里面都有延时的，而且大部分设备是正常的。且重启的时间也不定，最短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的次数。

更多详细资料获取请点击：合宙文档资料中心