2131E 维测功能 指导书
本文档面向 Hi2131E 故障分析人员，说明死机信息的获取、解析结果字段及常见异常的定位方法。Hi2131E 以固件形式交付，本文档聚焦 DebugKits、J-Link、DBG_UART、解析结果和符号文件的使用流程。
文档说明
本文档主要描述了使用单板死机维测问题定位指导，包括死机信息获取、死机信息的解析以及死机问题的定位等内容。
维测能力与使用边界
2131E 死机维测由“现场采集—数据导出—解析—字段校验—异常分类—符号定位”组成。
| 能力 | 交付或获取方式 | 使用边界 |
|---|---|---|
| DebugKits Message 死机摘要 | DebugKits 已有消息通路 | 适合快速查看死机原因和调用栈日志 |
| DebugKits 宕机信息导出 | DebugKits 的 System/宕机信息查看 | 适合实验室及现网外场采集 |
| J-Link 全内存导出 | J-Link 调试器和命令行 | 仅限研发实验室；需要禁止异常自动重启 |
| DBG_UART 内存导出 | 已启用对应特性的固件及配套脚本 | 属于补充采集方式 |
| 解析与符号定位 | 匹配版本的解析脚本、map/elf/lst |
从对应版本交付包或技术支持渠道获取 |
快速获取并分析死机信息
流程设计
快速操作
- 优先连接 DebugKits。若设备能够重启并重新连接，先从 Message 界面查看 1 条死机原因日志和 2 条调用栈日志。
- 需要完整记录时，使用 DebugKits 的“宕机信息查看”导出 A 核、C 核或最近一次 A/C 核死机数据。
- 仅在实验室且需要保留现场时，按受控流程设置
NV_ID_SYSERR_UNREBOOT=0x554E5253，再使用 J-Link 或 DBG_UART 导出。问题定位结束后恢复量产配置，避免设备异常后无法自动重启。 - 使用与固件版本匹配的解析脚本生成日志。解析脚本可从对应版本交付包或技术支持渠道获取。
- 先检查记录起止 magic 和
phase，确认数据有效；再查看main_type，进入看门狗、CPU 异常、LiteOS panic 或 panic 分支。 - 需要符号化定位时，同时准备对应版本的
map、elf、lst文件、固件版本信息和复现步骤。
结果判断
- 起止 magic 正确且
phase表明记录已写入完成，才能继续使用其上下文和调用栈。 main_type用于选择后续定位分支；具体取值和字段含义见死机信息内容说明。- 解析失败、字段不完整或符号地址无法解析时，首先核对采集文件、解析脚本和符号文件是否来自同一固件版本。
死机信息获取方法
死机信息可通过以下方法获取：
- 通过DebugKits工具的Message界面输出。
- 通过DebugKits工具的宕机信息查看功能导出。
- 连接J-Link调试器导出。
- 通过DBG_UART导出（需要特性宏和FAE提供的脚本）。
前三种是常用获取方法，DBG_UART是补充方式。在研发测试实验室调试测试场景下，可使用DebugKits或J-Link，并在具备配套条件时使用DBG_UART；现网外场场景下适用DebugKits工具导出方法获取；各场景下连接MCU则可在MCU侧获取死机信息。
须知： 在连接J-Link调试器定位死机问题的过程中，为防止单板发生异常后自动重启，导致获取的死机信息无法查看，需要在定位问题之前将A核中死机不重启NV项（NV_ID_SYSERR_UNREBOOT）的值修改为0x554E5253，NV值的修改请参见《HiDiTingV100 NV 存储用户指南》，并重启单板。 由于单板发生异常后，不能正常重启是高风险问题，因此该功能仅可在实验室使用。
DBK工具Message界面输出
当单板与DebugKits工具处于连接状态时，如果单板发生了死机，DebugKits工具会在单板重启后进行重新连接，并将死机信息输出到DebugKits工具的Message界面中，如图1所示，死机信息将由3条日志组成，分别为1条死机原因日志（消息ID为LOG_LAST_SYSERR_LOG）和2条死机调用栈日志（消息ID为LOG_LAST_SYSERR_STACK_LOG）。
DBK工具导出死机信息
通过下方步骤，使用DebugKits工具导出Flash中的死机信息。
-
连接DebugKits工具，参考《DebugKits工具使用指南》中的“内存读取”章节，选择System选项下的宕机信息查看，完成以下信息：
- 选择保存文件的路径。
- 选择导出名称。
- soc_dump_acore_crash_memory：导出A核死机信息。
- soc_dump_pcore_crash_memory：导出C核死机信息。
- soc_dump_crash_flash：导出最近一次A/C核死机信息。
-
单击“开始Dump(B)”按钮进行死机信息的导出。
-
使用
2131_analyse_syserr.py脚本解析导出的 bin 文件，得到死机信息的 log 文件。该脚本不在本仓库中，可从匹配的 2131E 版本交付包或技术支持渠道获取。该 log 文件中包含的死机信息可通过“死机信息内容说明”中的字段解读死机信息。
连接J-Link调试器导出
- 导出死机内存前，需要确保单板不会因死机导致重启，因此需要提前修改A核中NV_ID_SYSERR_UNREBOOT这个KV项的值为0x554E5253，配置单板在发生异常时不会重启。
- 确保当前环境已连接J-Link。
-
使用J-Link命令脚本连接到J-Link工具，通过J-Link工具导出全内存信息。其中执行命令包括：
- halt或h：暂停CPU运行。
-
savebin文件名（完整路径）地址（默认16进制）大小（默认16进制）：导出内存内容。本文对应版本中，A核RAM的起始地址为0x200000，大小0xC0000；C核RAM起始地址为0x270000，大小为0xB8000。不同版本或内存布局不能直接复用这些地址，具体命令执行如下：
图 1 执行结果
将导出的bin文件以及编译版本时生成的“application_cat1.map/application_cat1.elf/application_cat1.lst”,“protocol_cat1.map/protocol_cat1.elf/protocol_cat1.lst”文件一起打包发送给FAE，获取解析结果。
通过DBG_UART导出
- 该功能需要在对应的2131E固件中开启SUPPORT_DBG_UART_EXPORT_SYSERR_MEM特性宏；使用前请确认固件版本支持该特性。导出死机内存前，需确保单板不会因死机而导致重启，因此需提前将A核中NV_ID_SYSERR_UNREBOOT这个KV项的值修改为0x554E5253，配置单板在发生异常时不会重启。
- 确保当前环境DBG_UART接线正常。
-
通过FAE获取内存导出脚本“export_mem_2_bin.py”，使用方式如下。
在脚本所在的路径下打开cmd并执行以下命令：
COMX：DBG_UART对应的COM口编号。
-b ：导出内存所用的波特率，默认115200。
图 1 执行命令
图 2 导出的文件
将导出的bin文件及编译版本时生成的“application_cat1.map/application_cat1.elf/application_cat1.lst”文件一起打包发送给FAE，获取解析结果。
死机信息内容说明
soc_syserr_head
可在生成解析结果文件中搜索以下成员名查看相关数据。
成员 |
描述 |
|---|---|
magic |
完整有效的死机信息对应该值为：EXT_SYS_ERR_START_MAGIC(0x73797373)。 |
ver |
死机结构版本。 |
size |
soc_syserr_info对应的大小。 |
soc_syserr_basic
可在生成解析结果文件中搜索以下成员名查看相关数据。
成员 |
描述 |
|---|---|
crash_sec |
死机发生的时间（此处为距离上电后的绝对时间，包含深睡时间）。 |
ver |
死机发生时的image版本号。当前维测记录不写入该字段。 |
main_type |
死机的主类型：
|
sub_type |
死机发生子类型（当main_type为5时，可表示父函数地址、任务名称、任务ID等内容，需要结合其他死机信息综合判断）。 |
core |
死机发生的核。 1：C核； 2：A核。 |
phase |
死机信息记录的存储阶段。存储死机过程中可能发生2次异常，从而导致死机信息存储不完整（例如，踩内存场景，遍历内存池造成2次死机），当该值为SOC_SYSERR_SAVE_PHASE_FINISH（0x778899AA）时，表示进行了完整的死机存储。 |
soc_syserr_cmn_data
可在生成解析结果文件中搜索以下成员名查看相关数据。
成员 |
描述 |
|---|---|
data[4] |
不同的崩溃场景存储不同的信息，常用于panic定位。 |
通用数据结构使用 data[4] 表示字段，部分 panic 场景按 data[0]～data[4] 解释字段。定位时应以与固件版本匹配的解析结果为准。
soc_syserr_context
soc_syserr_context中记录了死机时的CPU状态，表1中仅对具有特殊功能的成员进行描述，且只有在SOC_SYSERR_CPU_EXEC和SOC_SYSERR_WATCH_DOG场景下意义准确。可在生成解析结果文件中搜索以下成员名查看相关数据。
表 1 soc_syserr_context成员描述
成员 |
描述 |
|---|---|
mepc |
死机发生时的pc值。 |
ra |
调用死机发生函数的地址（返回地址）。例如，死机发生在A函数，在x地址调用的A函数，则ra为x指令的下一条指令。 |
sp |
死机发生时的栈指针。 |
mstatus |
死机发生时的CPU状态寄存器。 |
mtval |
死机发生时程序预访问但CPU和逻辑限制访问的目标地址，Load、store异常时，该值有意义。 |
mcause |
死机原因，已经转换为sub_type。 |
ccause |
死机原因，CPU子类。 |
soc_mem_info
死机发生时的内存池状态。mem_info的具体成员信息请参见头文件“soc_mem.h”中的“soc_mem_info”结构体定义。
soc_syserr_stack
可在生成解析结果文件中搜索以下成员名查看相关数据。
成员 |
描述 |
|---|---|
in_isr |
死机是否发生在中断中。 |
sp_in_stack |
死机发生时的sp是否在合法栈空间中。 |
id |
死机发生时的任务ID。即保存当前线程任务执行状态的地址，具体可参考LosTaskCB结构体。 |
top |
栈上边界。 |
bottom |
栈下边界。 |
sp |
栈指针。 |
Peek |
栈峰值。死机发生在任务中时，该值有意义。 |
Name |
发生死机的栈的名称。 |
Stack |
死机时刻的函数调用栈。 |
soc_syserr_tail
可在生成解析结果文件中搜索以下成员名查看相关数据。
成员 |
描述 |
|---|---|
magic |
完整有效的死机信息对应该值为：EXT_SYS_ERR_END_MAGIC（0x73797365）。 |
死机问题定位
查看死机信息有效位
成员 |
描述 |
|---|---|
soc_syserr_head[magic] |
EXT_SYS_ERR_START_MAGIC（0x73797373）：死机信息有效。 |
soc_syserr_tail[magic] |
EXT_SYS_ERR_END_MAGIC（0x73797365）：死机信息有效。 |
soc_syserr_basic[phase] |
|
查看main_type
通过查看死机信息中的main_type字段，判断当前死机的主类型，确定定位方向。
成员 |
描述 |
|---|---|
main_type |
|
看门狗重启问题定位
看门狗死机导致的重启问题，大概率为代码中存在死循环（包含次数很大的循环）或某个业务一直被执行（如灌包），使得IDLE任务无法及时得到调度，在规定时间内没有进行踢狗而导致看门狗超时造成的重启。通常可以通过表1中的信息并结合lst文件确定具体的死机位置。
表 1 看门狗死机的关键信息
成员 |
描述 |
|---|---|
mepc |
通过mepc确定看门狗到期时的pc。根据概率推测可知，该代码基本为死循环中会调用的代码。 |
ra和栈 |
如果mepc在通用函数中，如memcpy函数中，可以通过ra和栈内容进一步确认函数调用流程。 |
CPU异常触发重启问题定位
通过sub_type成员描述内容，可确认CPU异常触发重启具体的死机原因。
成员 |
描述 |
|---|---|
sub_type |
|
liteos panic异常定位
成员 |
描述 |
|---|---|
sub_type |
存储reson、LiteOS panic死机的子类型。
|
cmn.data[0]~cmn.data[4] |
存储死机相关信息，如父函数地址、任务名称、任务ID等内容，需要结合其他死机信息综合判断。 |
panic异常定位
调用void panic(panic_id_t source, uint32_t code)函数触发的异常。
成员 |
描述 |
|---|---|
sub_type |
存储触发的panic的模块id（panic_id_t ）。该类型在对应2131E版本的“protocol/cat1/lte/infra/comm/inc/panic.h”中定义，应结合匹配版本的解析结果确认panic死机子类型。
|
注意事项与常见问题
注意事项
NV_ID_SYSERR_UNREBOOT=0x554E5253会使系统异常后不自动复位，仅限研发实验室保留现场使用。采集完成后必须恢复产品规定值并验证异常复位行为。- J-Link 中的 A 核
0x200000/0xC0000、C 核0x270000/0xB8000只适用于本文对应版本及内存布局。 - DebugKits 工具字符串中的
pcore与正文中的 C 核是同一采集对象的不同表述；工具项名称必须保持原样。 - 使用 J-Link 送交分析时，应同时提供 A 核的
application_cat1.map/.elf/.lst和 C 核的protocol_cat1.map/.elf/.lst；使用 DBG_UART 时，本文流程要求提供application_cat1.map/.elf/.lst。两种清单不要混写。 - 死机数据、解析脚本和符号文件必须来自匹配版本。版本不一致时，即使地址能够解析，也可能得到错误函数名或行号。
常见问题
| 现象 | 可能原因 | 处理方法 |
|---|---|---|
| DebugKits 重连后没有死机日志 | 数据未保存、消息过滤或工具数据库不匹配 | 检查 Message 过滤条件、工具数据库和固件版本，必要时使用宕机信息导出 |
| 导出的 bin 无法解析 | 解析脚本、采集类型或固件版本不匹配 | 记录 A/C 核来源并获取对应版本的解析脚本 |
| J-Link 无法读取目标地址 | 连接、供电、CPU 状态或内存布局不匹配 | 确认目标已 halt，并核对本文版本对应的地址和大小 |
| DBG_UART 脚本找不到串口 | COM 号、接线或串口占用错误 | 核对 DBG_UART 接线，关闭占用串口的软件并替换命令中的 COMX |
phase 不是完成值 |
保存过程中再次异常或记录不完整 | 将现有数据作为不完整记录处理，结合其他日志重新采集 |
| 地址无法符号化 | 缺少或使用了错误版本的 map/elf/lst |
重新获取与发生异常固件完全一致的符号文件 |
| 设置不重启 NV 后设备无法恢复 | 异常现场被保留，系统不会自动重启 | 仅在实验室执行；完成采集后恢复 NV 并按维护流程重启 |
相关资料
- DebugKits工具 使用指南：连接设备、查看 Message 和导出内存数据。
- 2131E NV 用户指南：
NV_ID_SYSERR_UNREBOOT的配置含义与风险。 - 2131E AT命令 用户指南：查询崩溃信息及相关 AT 命令说明。