网站建设运维自查问题清单,国内做钢铁的网站,怎样在百度上推广,wordpress 收不到邮件Air780E/Air780EP/Air780EQ/Air201模块遇到死机问题如何分析
简介 本文档适用于合宙Air780E、Air780EP、Air780EQ、Air201 关联文档和使用工具#xff1a; 从Ramdump里分析内存泄漏问题 无法抓底层log的情况下如何导出死机dump Luatools下载调试工具 EPAT抓取底层日志 F…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口UART0DBG_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 logluatools会自动识别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版本还需要通过发送以下指令配置
ATECPCFGlogCtrl,2 // 输出全部日志
ATECPCFGlogPortSel,1 // 只从DBG_UART串口输出日志
ATECPCFGlogBaudrate,6000000 // 设置波特率为6MB 遇到死机怎么办
设置死机不重启方法
AT固件发送 ATECPCFG“faultAction”,0 或者 AT*EXASSERT1 指令开启死机不重启。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字样可以看到断言的位置
如果没有底层logramdump里需要看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 accessimprecise 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也丢完或者压根没法抓建议通过删减代码加打印语句等方法来定位出错的语句多次尝试缩小范围直到成功有经验对源码了解的能加快这一进度。 误这种常见的函数指针用出问题导致函数退出时PC指针已经不能指向正确的代码指令从而执行了非arm的指令
如果ramdump的信息都不完整底层log也丢完或者压根没法抓建议通过删减代码加打印语句等方法来定位出错的语句多次尝试缩小范围直到成功有经验对源码了解的能加快这一进度。
咨询电话合宙市场部葛理想13723245337
企业微信
