在前文中，我們已經(jīng)詳細(xì)闡述了合宙基于移芯平臺(tái)的模塊遭遇死機(jī)問題的根源探尋策略與解決路徑的構(gòu)建。

今天，我們將進(jìn)一步深耕細(xì)作，聚焦內(nèi)存死機(jī)這一具體現(xiàn)象，探討其背后的原因以及相應(yīng)的解決策略。

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

關(guān)聯(lián)文檔和使用工具：

移芯平臺(tái)模塊出現(xiàn)死機(jī)問題分析

trace32工具下載

EPAT抓取底層日志

一、從Ramdump里分析內(nèi)存泄漏問題

對(duì)于遇到內(nèi)存不足死機(jī)的問題，可以從ramdump里找出哪些函數(shù)在消耗ram。

進(jìn)入trace32后，在自動(dòng)彈出下發(fā)圖片的窗口里能找到哪個(gè)函數(shù)在哪個(gè)task里用了多少ram沒有歸還，如果遇到哪個(gè)API大量申請(qǐng)了ram沒有歸還，基本上就是問題點(diǎn)了

為了查找方便，在trace_node選擇某個(gè)數(shù)據(jù)，框里面右鍵 -> 點(diǎn)擊format

上圖里看到0x00868909 這個(gè)API在消耗大量的ram，從map文件，或者從trace_32工具菜單 view -> symbols -> browes 里搜索，Ctrl+F，或者Cov - > list functions，就能找到函數(shù)名稱。

這樣查找問題解答方向上 就相對(duì)明確了。

二、從Ramdump里分析棧溢出

需要檢查下trace32里有沒有freertos文件夾，如果沒有可以在這里下載放到根目錄freertos

一般來說，棧溢出會(huì)有斷言的情況，但是也有代碼申請(qǐng)了一大塊?？臻g，導(dǎo)致棧底的ram沒有被改變，但是實(shí)際上代碼已經(jīng)操作了棧外空間，且freertos不會(huì)報(bào)錯(cuò)，燃石在trace32里能分析出來。

打開trace32 -> freertos -> stack Coverage -> List Stacks

可以看到ram使用情況，注意這里認(rèn)為?？臻g只有1KB，但是實(shí)際上可能是遠(yuǎn)超的，不過沒關(guān)系，如果max里是0%，說明還有很多?？臻g，不用去管

Tmr Svc這個(gè)task居然用到了93%

右鍵點(diǎn)擊紅框，在彈出菜單里選擇display memory->dump

距離溢出只有不到70字節(jié)，如果用戶代碼里有類似uint8_t temp[71]，那么很容易就操作了棧外的ram，死機(jī)就很正常了

詳細(xì)資料獲取請(qǐng)點(diǎn)擊： www.openluat.com

審核編輯 黃宇