又是異常重啟。。。讓人摸不到頭腦。
這幾天，看到客戶上報了重啟問題，說是查不出原因。
重啟現象是——有極個別裝置在工作中不定時反覆異常重啟，大部分裝置正常；反覆重啟裝置，有時候又能持續正常工作。
溝通中很明顯感覺到了客戶的著急和無奈，必須找出背後原因，解決客戶問題！
一、查詢線索
按常規流程先詢問客戶開發模組、開發方式，並要求提供對應日誌。經確認如下：
開發模組：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的次數。