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

covid

嵌入式软件调试偶发性问题技巧
  J) _/ t% ]* a- L$ F' \

" l8 [. S0 ]! I5 R  w+ u7 [4 }经常有朋友问我，该如何调试程序的偶发性问题？
0 x. w; L: W0 D- Y) h大家所谓的偶发性问题，其实就是很难复现、较难定位的问题。比如，在家里验证了N遍，固件一发布到客户现场就各种宕机；现场刚调试得明明白白，正准备离开客户公司大门，客户来电话了，然而折返复现问题，却死活不出现；明明有些代码“对天发誓”不会存在问题，而程序运行久了总有概率在那一块翻车，等等。
- f: Z# _0 b$ M, G8 W: K; f, ^" w0 r
9 f4 h1 y7 W9 L0 X) j确实遇到这样的问题属实让人头皮发麻，比如你在深圳，客户现场在北京，出了一些偶发性问题，很多朋友心里想要是能飞过去插个仿真器那这些bug不是分分钟的事情吗？其实也不是不可能，远程仿真工具嘛~最怕客户现场没有网络~
6 u* `+ O$ D0 r  v
9 u0 I' n2 _6 K2 R: M* J不过问题是有些bug不是随随便便给你面子复现的，甚至它隔个好几天问候一下你，总不能可能一直干等吧。

那么，对于这样的偶发性问题，我们到底该如何解决呢？
3 P( p( K) h* T& A0 U9 D
0 x5 z; c5 Y+ n1
: a; b: h" J8 N. M. }% O- g
- Y/ u5 U" a+ z: g, _- S; P8 S5 }! C, |知己知彼

首先，我们要充分的了解和把握出现问题的情景，比如问题出现时，是否客户做了什么操作、是否有停过电、大概在几点出现的、是否存在一定的规律、如果现场有多台机器，他们是否都会出现类似的问题等等。
只有充分了解了问题现场的详细发生情景，你才能快速的排除一些问题、缩小定位的范围，最重要的是分清楚到底是软件问题，还是硬件问题！
我见过很多老实巴交的软件朋友一遇到问题就打开工程查软件bug，那只会让我觉得你头秃是有原因的。
同时，也要对所收集的信息进行一些筛选和排除，因为一个现象对于不同的人会有不同的描述，有些客户并不是专业人士一些现象描述得不清楚，有可能把你带入误区。
; x  v# g* b  z, S: T; P所以，结合系统日志信息、目前设备状态和售后或者客户描述，进行初步的问题定位。
. I  X% ]: Y7 e! ]2

% F' }6 c: h, Z) {3 }; B/ F不能全靠猜
# n+ _2 S2 N+ O1 x+ q- _3 k0 M( W
5 K. F! y- X8 s& u* g% ^1 j很多朋友了解了具体的问题以后就抱着猜一猜的心态，凭感觉去修改代码，如果问题不再出现就认为是修护了该问题，这样的做法是不科学的。
作为一名工程师还是要本着务实求真的态度，一步一步的缩小问题的范围，通过安插测试程序来检测难以复现的偶发性问题，让工程师来主动查找bug，还不如安插一些bug捕捉程序来自动监测bug，这样也会更加的精准。
多模拟一些问题出现频率较高的环境和状态，比如有一个问题专门在晚上发生，那么我们可以构建一个晚上的环境，比如系统时钟的调整、系统访问用户的增加或者晚上的一些特殊操作等等。
& p9 x4 V3 n% h/ K2 ~$ r. K( j' K' I从而进一步降低复现问题的成本。
. F9 ~5 @+ ~' I' f" X3
: F! L6 a/ p- E# F
没有仿真器怎么办？
" m" @+ ?' t* Q' P* a2 U8 [9 R1 X
/ O  z) ~2 @5 g( I很多朋友已经习惯了用仿真器来进行问题的排查，确实仿真器几乎暴露了系统运行的所有状态，再加上一些条件断点、查看工具等的加持，bug基本上跑不了。
( S* S$ p: t/ u) `1 W) G) h在产品开发的前期阶段，这样的开发和解决问题方式是高效的，但这样的愿景在真正的产品上线以后是比较难实现的，比如一些防水密封或者大型的设备等。
所以，还是要借助一些其他手段帮助我们分析问题，依靠一些通信协议把相应的数据传输出来进行分析。
打印日志信息是大家经常想到的，也是一种老牌调试办法了~对于大部分对时间要求不敏感的问题是最合适的调试手段了；如果是离线运行的话，可以找一片存储区，比如Flash或者SD等，或者自带文件系统的可以直接写到文件中，以便后续拷贝或者上传出来进行分析。
然而日志打印比较耗时，对于很多偶发性问题，可能就是一闪而过的事情，而且最可怕的莫过于你的日志打印里面也有bug，所以寻找一个越简单越好。
! U- R" R9 S5 z5 k& c4 i! }直接通过构造问题出现的判断条件，然后赋予不同的调试变量不同的标识，当问题出现以后进入并保存相应的信息到调试变量中，最终接上上位机就可以看到，简单直接。
- E9 l* @- k6 k4 Q# I* J然而，有些降成本的产品连个通信都没有，那该怎么玩呢 ? Led、IO口你值得拥有，他们都可以通过高低电平的状态来传递信息给外界，如果你够狠的话，还可以自己定义一套单总线通信协议。
4
  e; z2 f9 w) \
直接Game Over

* G' |9 r6 ^# R% z* ^: p+ _- z当然，还有一种是直接死机了，这种问题是比较头疼的，如果只是像hardfault这样的可循异常，倒可以在死机前进行现场环境保存工作。
! Q, c& [1 K  x1 `" p3 r: q3 S7 {同样对于直接复位的情况，大家也可以在程序入口地址处通过打印相关的信息来供分析，比如寄存器的值等内存信息，来回溯到之前的复位点。
, Y2 [3 `$ H& a. a但是，对于程序既不运行也不复位的情况，就没那么好处理了，很多人会想到实时的记录一些变量和可疑条件等等，也未尝不是一种办法把，大概率还是会漏检。
不过，这种情况下大概率还是跟硬件脱不了干系，务必先排查电源电压、功率等干扰问题，再考虑采用屏蔽二分法进行排查代码~
9 r  o' M/ n( a5 A% @1 y好了，基本上调试偶发性bug就这么多分享了，希望这篇文章能对大家有所帮助。

songwritten

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

分贝网

是好:victory: