合宙 Air780E/Air780EP/Air780EQ/Air201模块遇到死机问题如何分析

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也丢完，或者压根没法抓，建议通过删减代码，加打印语句等方法来定位出错的语句，多次尝试缩小范围，直到成功，有经验，对源码了解的，能加快这一进度。