死机分析
📎 原始文档：https://www.kdocs.cn/l/coGBef6Xm4Hq 死机分析
异常信息表
instruction fetch hmem excption (预取指令异常) (读写数据异常，非法地址不属于hmem区域)
read hmem excption (读数据地址) (读数据异常，数据读越界包括数组以及结构体相关)
write hmem excption (写数据地址异常) (写数据异常，数据写越界包括数组以及结构体相关)
stack overflow err (栈溢出异常) （堆栈空间异常，主要查看是否对应任务局部数组等比较大以及函数嵌套层数过多）
div0_err (除0异常)
illegal_err (非法指令异常) （非法地址读写 一般出现代码错误比较多比如说函数指针错误）
misalign_err (不对齐异常，不可屏蔽) （非对齐操作，一般出现内存释放后还访问内存导致）
system excption (系统异常)
icache excption (icache异常)
lg0 access mmu excption（printf\sprintf...传参错误）
dcache excption (dcache异常)
调试异常死机方法 【金山文档】 打印调试方法
打印调试方法.otl
查看文档中第五点获取所对应的文件一般定位死机方法
需要准备一份完整死机打印log以及sdk.lst文件
参考分析以下问题 【金山文档】 sdk_lst
https://kdocs.cn/l/ccQs7JN2PBMr
【金山文档】 debug_log
debug_log.TXT参考以下分析流程
目前分析到这里大部分死机可以找到死机原因
堆栈回溯
第三点主要是针对一些reti指针死在用户代码或者应用层代码进行分析
一般还存在定位到的死机位置位于断言函数或者底层库中代码，需要自己分析可以进行堆栈回溯找到对应应用层死掉的位置
使用第三点中死机log和sdk.lst文件继续分析
目前知道死在ui_core.c 62 ui_core_redraw函数中，如果需要继续回溯上层调用的函数，需要结合打印log中的usp和sdk.lst文件进行回溯
可以根据上面分析流程类推死机问题分析（除了内存改写或者死在中断）
分析死机经验
一般遇到misalign_err对齐错误直接看另外一条死机信息会比较准确 2.如果遇到reti和rets找到的函数中没办法直接回溯，建议通过usp找到 xx xx xx 06(例如上面的08 47 04 06 )数据作为搜索然后根据原来回溯方式，如果这个地址是正确的话，那么理论上找到的地址也是xx xx xx 06格式的这里以701为准，其他系列可以根据sdk.lst等同。