嵌入式软件调试偶发性问题技巧

covid

嵌入式软件调试偶发性问题技巧

: C' r/ [& V) K! G
& `1 i/ i' a$ ?0 C9 h& X1 x经常有朋友问我，该如何调试程序的偶发性问题？
大家所谓的偶发性问题，其实就是很难复现、较难定位的问题。比如，在家里验证了N遍，固件一发布到客户现场就各种宕机；现场刚调试得明明白白，正准备离开客户公司大门，客户来电话了，然而折返复现问题，却死活不出现；明明有些代码“对天发誓”不会存在问题，而程序运行久了总有概率在那一块翻车，等等。
, k+ S. f* {' R3 j% I
确实遇到这样的问题属实让人头皮发麻，比如你在深圳，客户现场在北京，出了一些偶发性问题，很多朋友心里想要是能飞过去插个仿真器那这些bug不是分分钟的事情吗？其实也不是不可能，远程仿真工具嘛~最怕客户现场没有网络~
8 w9 D1 j7 E8 s0 d
7 u+ L/ Q4 n4 x8 ?不过问题是有些bug不是随随便便给你面子复现的，甚至它隔个好几天问候一下你，总不能可能一直干等吧。

* k8 n! H  m5 u% |" I6 u那么，对于这样的偶发性问题，我们到底该如何解决呢？

, m: c, ]0 b1 k+ ?" r6 ~2 ?! c1
4 x. \2 {: m, d" {& a) e3 I
) F" u7 e) Z8 z1 F知己知彼

首先，我们要充分的了解和把握出现问题的情景，比如问题出现时，是否客户做了什么操作、是否有停过电、大概在几点出现的、是否存在一定的规律、如果现场有多台机器，他们是否都会出现类似的问题等等。
* D' k6 f$ o6 s* x, e3 t只有充分了解了问题现场的详细发生情景，你才能快速的排除一些问题、缩小定位的范围，最重要的是分清楚到底是软件问题，还是硬件问题！
* D  {' Y  n# u. T, s) k我见过很多老实巴交的软件朋友一遇到问题就打开工程查软件bug，那只会让我觉得你头秃是有原因的。
同时，也要对所收集的信息进行一些筛选和排除，因为一个现象对于不同的人会有不同的描述，有些客户并不是专业人士一些现象描述得不清楚，有可能把你带入误区。
所以，结合系统日志信息、目前设备状态和售后或者客户描述，进行初步的问题定位。
. Q2 d* W% M) [2
+ y5 ~) k, v, b
不能全靠猜
: o4 r( Z$ v" Y
9 w1 }8 O) j% C8 l% L' W# ]& i2 ^! o7 ?很多朋友了解了具体的问题以后就抱着猜一猜的心态，凭感觉去修改代码，如果问题不再出现就认为是修护了该问题，这样的做法是不科学的。
1 \3 O$ m# v  G. s# g& c0 A作为一名工程师还是要本着务实求真的态度，一步一步的缩小问题的范围，通过安插测试程序来检测难以复现的偶发性问题，让工程师来主动查找bug，还不如安插一些bug捕捉程序来自动监测bug，这样也会更加的精准。
多模拟一些问题出现频率较高的环境和状态，比如有一个问题专门在晚上发生，那么我们可以构建一个晚上的环境，比如系统时钟的调整、系统访问用户的增加或者晚上的一些特殊操作等等。
  W1 D3 w8 ?9 t% p" R从而进一步降低复现问题的成本。
4 D$ L6 |) Z7 R% ~$ `* N# J+ p5 s8 S3

, f) M* V& c+ x: f: A2 ^没有仿真器怎么办？
- y" k! R6 Y% q9 a' L
3 p$ ^0 ~: u. K4 i4 K4 U0 A很多朋友已经习惯了用仿真器来进行问题的排查，确实仿真器几乎暴露了系统运行的所有状态，再加上一些条件断点、查看工具等的加持，bug基本上跑不了。
0 D  C3 }( e/ x" ~1 W. h7 ~在产品开发的前期阶段，这样的开发和解决问题方式是高效的，但这样的愿景在真正的产品上线以后是比较难实现的，比如一些防水密封或者大型的设备等。
) V+ L/ s+ _! S5 s. K7 C4 v5 {所以，还是要借助一些其他手段帮助我们分析问题，依靠一些通信协议把相应的数据传输出来进行分析。
8 K9 c( _" T! S4 h9 ~3 E2 `; S打印日志信息是大家经常想到的，也是一种老牌调试办法了~对于大部分对时间要求不敏感的问题是最合适的调试手段了；如果是离线运行的话，可以找一片存储区，比如Flash或者SD等，或者自带文件系统的可以直接写到文件中，以便后续拷贝或者上传出来进行分析。
+ J3 V2 L& z* u2 l0 u7 [: Y然而日志打印比较耗时，对于很多偶发性问题，可能就是一闪而过的事情，而且最可怕的莫过于你的日志打印里面也有bug，所以寻找一个越简单越好。
直接通过构造问题出现的判断条件，然后赋予不同的调试变量不同的标识，当问题出现以后进入并保存相应的信息到调试变量中，最终接上上位机就可以看到，简单直接。
$ e2 u0 }, z5 M' L8 w然而，有些降成本的产品连个通信都没有，那该怎么玩呢 ? Led、IO口你值得拥有，他们都可以通过高低电平的状态来传递信息给外界，如果你够狠的话，还可以自己定义一套单总线通信协议。
4
9 g) q' k  c. ?
直接Game Over
. A8 r6 y: s4 @4 o' J5 U% I7 \7 |
当然，还有一种是直接死机了，这种问题是比较头疼的，如果只是像hardfault这样的可循异常，倒可以在死机前进行现场环境保存工作。
同样对于直接复位的情况，大家也可以在程序入口地址处通过打印相关的信息来供分析，比如寄存器的值等内存信息，来回溯到之前的复位点。
但是，对于程序既不运行也不复位的情况，就没那么好处理了，很多人会想到实时的记录一些变量和可疑条件等等，也未尝不是一种办法把，大概率还是会漏检。
; U  C; O, W7 X6 e- ?不过，这种情况下大概率还是跟硬件脱不了干系，务必先排查电源电压、功率等干扰问题，再考虑采用屏蔽二分法进行排查代码~
好了，基本上调试偶发性bug就这么多分享了，希望这篇文章能对大家有所帮助。

songwritten

嵌入式软件调试偶发性问题技巧 ！:handshake :lol

分贝网

是好:victory: