日志与崩溃分析¶
日志是产品的一部分，不是临时的调试手段。完善的日志可以缩短启动调试、现场排查和工厂故障调查所需的时间。
应在首次现场测试前设计日志机制。设备在现场发生故障后，你只能获得固件预先准备保存或输出的数据。
最低日志配置¶
每个固件构建都应记录：
- 固件版本。
- SDK 分支或提交。
- 开发板型号和硬件版本。
- 启动原因。
- 分区布局版本。
- 主要子系统初始化结果。
- 启动失败时输出的崩溃信息或断言信息。
崩溃分析流程¶
- 在基线固件已验证可正常运行的开发板上复现问题。
- 从复位开始采集完整启动日志。
- 保存与故障版本完全对应的二进制文件和符号文件。
- 使用思澈科技（SiFli）的工具解码断言（assert）或转储（dump）输出。
- 检查栈空间大小、内存归属、DMA 缓冲区及缓存维护。
- 参照最接近的 SDK 示例缩小问题范围。
日志级别¶
表：日志级别
| 阶段 | 建议日志 |
|---|---|
| 板级启动调试 | 详细的外设和启动日志。 |
| 功能开发 | 围绕正在验证的功能输出模块级调试日志。 |
| 功耗调优 | 尽量减少日志，因为日志输出本身会影响功耗。 |
| 发布候选版本 | 警告、错误、版本、启动原因和关键健康检查。 |
| 现场诊断构建 | 围绕疑似子系统输出有针对性的日志。 |
崩溃报告应包含的信息¶
- 包含从复位到崩溃的完整日志。
- 标明发生故障时对应的固件二进制文件。
- 包含符号文件或可复现构建。
- 说明未经修改的 SDK 示例是否也会出现相同崩溃。
- 列出已连接的外设和供电来源。
- 说明全片擦除并重新烧录后，崩溃是否仍然存在。
最后更新: