?又是異常重啟。。。讓人摸不到頭腦。

這幾天，看到客戶上報了重啟問題，說是查不出原因。

重啟現象是 ——有極個別設備在工作中不定時反復異常重啟，大部分設備正常；反復重啟設備，有時候又能持續正常工作。

溝通中很明顯感覺到了客戶的著急和無奈，必須找出背后原因，解決客戶問題！

一、查找線索

按常規流程先詢問客戶開發模塊、開發方式，并要求提供對應日志。經確認如下：

開發模塊：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的次數。

?審核編輯 黃宇