单片机学习日志第06篇：深入解析日志分析过程

背景

在工程开发中，软件一旦由开发工程师传递给他人（试验、客户），出现问题时往往无法通过debug的方式进行分析。问题产生的原因方方面面，可能是硬件、软件、试验环境、测试用例等，如果软件工程师可以完美复现问题，那么在本地进行分析也是可以的。但是情况一般没有那么顺利，这个时候就需要用到log分析法来对问题进行排查，以下是我最近在工作中用log分析总结的一些经验，分享给大家。

举例说明一：

我将开发的软件传递给到试验工程师后，收到了一个问题上报：用于监视芯片间通信状态的信号在休眠唤醒后会有报错，唤醒的第一帧报文中上报了通信状态异常，且持续了14帧故障才被清除，这是不符合软件设计的预期的。

首先明确该部分软件的设计：芯片的通信状态在初始化时会被初始化为通信正常（以下简称normal），发生通信故障后（通过回读监视通信是否正常）需要通过固定时间的滤波才会将故障置为通信丢失（以下简称lost），后续转换为normal也有相同时间的滤波。基于上述设计可以断定一个情况，软件正常运行状态下，第一帧报文必定是normal，即便有故障也要经过固定时间的滤波才会转变为lost，这就与试验上报的现象不符合了。

此时因为测试环境、硬件、软件、试验用例都固定了，最好的方式还是对log进行排查。但是我在一开始仍旧采用了本地复现的方法，可以发现无论本地复现的环境如何设置，唤醒后的第一帧报文必定是normal，本地无法复现实验环境下的问题。

对log进行分析，可以看到通信状态的第一帧为lost，这时就需要去本地采集原始log了（试验的log使用的是上位机软件采集下位机，我开发时的本地环境则是直接对下位机进行采集），可能log的采集方法有些区别。

补充一点，被监控的芯片的供电为mcu提供，供电开启的控制指令与其输出回采也体现在log中，这部分的log我也做了分析，可以看到从第一帧报文开始供电的输出指令就已经发出且回采值也为预期值。

到达试验场地后，复现场景后直接实用工具采集原始log，对其进行分析

1. 原始log中第一帧通信状态为normal，符合预期；

2. 原始log中第一帧5v回采为零，且后续也维持了多帧零的回采，说明此时被监控芯片没有供电，后续经过规定的滤波时间后通信状态从normal转变为lost是符合预期的；

3. 寻找供电输出的控制指令，发现控制报文并没有随着唤醒同一时间发出，而是等到状态转换为lost之后才开始输出报文，控制供电给到被监视的芯片；

结合上述内容得到结论，出现lost的原因是芯片唤醒后并没有第一时间给到控制指令打开被监控芯片的供电，导致其状态转变为lost，而试验环境下的log记录是从控制报文发出后才开始的，所以导致前面normal状态的报文没有被监视到；

结合本例子可以得到一些经验

1. 环境不同，log可能也会不同，尽可能去采集最原始的log来分析，避免丢帧情况的发生；

2. 无法复现的问题可以使用log法进行分析，需要注意报文中的时间关系，哪一个在前，哪一个在后，是否符合预期；