Air780E/Air780EP/Air780EQ/Air201模塊遇到死機問題如何分析

簡介

本文檔適用于合宙Air780E、Air780EP、Air780EQ、Air201

關聯文檔和使用工具：

從Ramdump里分析內存泄漏問題

無法抓底層log的情況下如何導出死機dump

Luatools下載調試工具

EPAT抓取底層日志

Flashtools_v4.1.9下載

luatools和EPAT這2個工具，具體使用方法要了解，本文不做深入講解，EPAT抓取底層日志文檔內有詳細使用說明

luatools用于捕獲從USB口的用戶log，即luat_debug_print輸出的log，僅用于csdk和luatos。AT版本沒有用戶log和用戶串口通道，需要使用EPAT工具抓取。

EPAT用于捕獲USB口，UART0（DBG_UART串口） 的底層log，在luatools沒有開啟的時候，EPAT同樣捕獲用戶log的大部分內容，這個時候用戶log會從底層log輸出，標識為luatos，等級為error，所以不要把用戶log當做error!

luatools捕獲用戶log時，自動識別GB2312還是UTF8編碼，也能正確打印64bit數據和浮點數據

EPAT只能識別GB2312編碼，不能正確打印64bit和浮點數據，在用UART0捕獲數據時會丟失部分log，尤其是優先級低的，所以用戶log的等級是error，優先級高

雙方都是USB口對接的情況下，USB虛擬串口沒有波特率限制，任意選擇，實際傳輸速率都是一樣的

為啥要區分用戶log通道和底層log通道，因為移芯不開放底層log解析方法

csdk固件默認死機后存儲死機信息到flash后重啟，luatos固件死機后會存儲死機信息到flash，然后等EPAT或者luatools抓取死機信息，等待大約40秒左右會重啟

出現死機問題分析

A 怎么抓LOG

A1 認識USB虛擬串口

由于電腦識別出來串口名字都是一樣的，因此需要從串口屬性上來區分對應功能，具體看下面截圖紅框

A1.1 用戶log通道

A1.2 底層log通道

A1.3 用戶串口通道

A2 抓log

如果使用EPAT工具抓取日志，說明請看 EPAT抓取底層日志文檔

A2.1 USB可用

建議方案1，只用luatools勾選USB打印模式即可，沒有配置上的要求，luatools會自動識別log通道，需底層log的，工具配置--》log--》勾選ap log，luatools會自動識別log通道，底層log保存在log/4gdiag。luatools版本必須在2.2.1及以上

建議方案2，直接用EPAT，按照EPAT手冊操作即可，如果luatools開著，工具配置--》log--》不要勾選ap log

A2.2 USB不可用

只能用EPAT通過DBG_UART抓LOG了，需要6M波特率抓取（USB轉TTL工具也要支持6M波特率），如果是AT版本還需要通過發送以下指令配置

AT+ECPCFG=logCtrl,2 // 輸出全部日志 AT+ECPCFG=logPortSel,1 // 只從DBG_UART串口輸出日志 AT+ECPCFG=logBaudrate,6000000 // 設置波特率為6M

B 遇到死機怎么辦

設置死機不重啟方法

• AT固件：發送 AT+ECPCFG="faultAction",0 或者 AT*EXASSERT=1 指令開啟死機不重啟。
• LuatOS開發：調用 mcu.hardfault(0) 接口開啟死機不重啟。
• CSDK開發：在task中執行 luat_debug_set_fault_mode(LUAT_DEBUG_FAULT_HANG); 開啟死機不重啟。

B1 EPAT抓底層log，固件設置成死機不重啟

EPAT會自動抓，并且自動彈出ramdump處理界面，按照手冊操作即可。

B2 luatools抓底層log，固件設置成死機不重啟

luatools也會自動抓ramdump，但是只能保存成文件，仍然需要用EPAT來手動進入處理ramdump界面，后續處理見B1

B3 固件設置成死機重啟，或者沒有工具抓底層log

幫助文檔：無法抓底層log的情況下如何導出死機dump

C 死機重啟原因常見情況分析

死機需要底層log和ramdump處理結果綜合判斷，luatos固件還要看用戶log，這里討論如何定位出錯代碼位置或者出錯原因

C1 luavm拋出的異常

這個看用戶log就行，如果開啟了errdump，還能在iot平臺上看到

C2 斷言死機

看底層log就可以，搜索EcAssert字樣，可以看到斷言的位置

如果沒有底層log，ramdump里需要看list source的代碼上下是不是調用了ec_assert_regs，然后在stackframe with local里看看調用順序，大概率能看到斷言的位置。

斷言死機如果是malloc失敗，那么就是ram不足了。

C3 內存不足

這是最常見的死機原因，而且9成9可以判斷是內存泄露，剩下也有可能malloc時的參數不對，申請了不可能申請到的空間大小。內存不足直接表現，C2中已有部分描述，如果有底層log，還可以從死機時打印的信息來判斷

這里表示動態分配ram時，最大的block只有712字節了，這是非常典型的內存不足引起的死機，正常來說，至少要有個70KB左右的空間來滿足LTE協議棧的需求

如果ramdump信息完整，則可以從ramdump里找到查找方向從Ramdump里分析內存泄露問題

C4 看門狗死機

在底層log和ramdump里都能看到，

ramdump里能看到最后停在NMI Handler里。

看門狗死機，要么死循環，要么操作時間太長，消除死循環，或者主動喂一下狗。壓力測試和RSA運算時特別注意一下。

C5 疑難雜癥

真正遇到hardfault時，需要先從底層日志里看死機的直接原因，也就是arm內核遇到的致命錯誤，當然多種多樣，常見的地址錯誤（常見data access）有數據存取時的總線錯誤（常見precise data access，imprecise data access等等），指令錯誤（常見switch to an invalid state (e.g., ARM)）等等。

以下個人經驗:

先要排除一下棧溢出的可能，一旦棧溢出，什么奇怪的現象都有可能發生，運氣好的，觸發斷言，運氣不好的，就什么錯誤都可能發生，任務鏈表都可能被破壞，導致ramdump里的信息都會缺失。

如果ramdump信息完整，則可以從ramdump大致分析出有沒有棧溢出現象從Ramdump里看棧溢出

如果ramdump的信息看起來完整，stackframe with local里調用順序也比較合理，那么就能定位發生問題的函數和語句，后續就看代碼調試吧，這是比較理想的情況。

地址錯誤的，大概率是讀寫了一個不可讀寫的地址，但是注意，有時候非ram和flash地址，直接讀取并不一定會出錯。

總線錯誤，大概率是數據對齊的問題，比如uint32_t *指針，去讀取一個uint8_t *指針指向的內容，一旦uint8_t *指針存放的地址不是32位對齊的，編譯器又沒有對應優化處理，死機是很正常的

指令錯誤，這種常見的函數指針用出問題，導致函數退出時，PC指針已經不能指向正確的代碼指令，從而執行了非arm的指令

如果ramdump的信息都不完整，底層log也丟完，或者壓根沒法抓，建議通過刪減代碼，加打印語句等方法來定位出錯的語句，多次嘗試縮小范圍，直到成功，有經驗，對源碼了解的，能加快這一進度。