调试的九个黄金准则---UNDERSTAND THE SYSTEM(一)

UNDERSTAND THE SYSTEM------理解系统

实例:

我有一个兼职是做一个基于微处理器的阀门控制系统.其原理框图如下:

系统通过磅称来进行采样,然后控制阀门,正像大多数工程师那样,我直接从我兄弟那拷贝了一个设计图.但是人品问题,我的不工作.当一个新的测量结果到来,去中断微处理器时,处理器却忽略了这个信号.由于是个兼职,我没有什么用于调试的工具,所以花了我很长时间才定位到这个问题,即接口芯片从磅称获取到了测量结果,但是在传递给微处理器时失败了.

我和一个IT男一块工作到半夜一点,心情沮丧到极点.IT男坚持让我翻出芯片手册,从头到尾的读一遍.也没什么好的办法,我照做了,芯片手册的第37页有一句话,说"这个芯片会在第一次撤销时钟信号时中断微处理器(估计就是在下降沿触发中断)",我的设计注定不会接收中断了,因为我为了节省硬件直接将时钟信号和地址信号合并在一起了.我兄弟的那个毕业设计只所以工作是因为他整个系统就没有用到中断(人品爆发).当我修改设计后,系统立马就工作了.

后来我向我爸爸描述这件事情,他告诉我说:这是一个常识----当所有尝试都失败的时候,去读说明书.

我不可能解决这个bug除非我明白那个接口芯片是如何工作的.反过来说,一旦我理解了那个芯片是如何工作的,这个bug就是那么显然的躺在那里.此刻,我明白对系统的了解是多么的有助于调试.我知道芯片是在那个条件下触发中断,碰巧我知道我的时钟信号和地址信号捆绑在一块了,所以一切都顺畅了.

你需要一点工作知识,你的系统要实现什么功能,它是如何设计的,在有些情况下你甚至都应该知道它为什么要这样设计.如果你不理解系统的某一个部分,经常会觉得问题就出在那个部分.

但是 要注意,理解系统并不意味这理解了问题,但是如果你想找出问题,你就必须知道系统应该是如何工作的.

我们可以通过以下方法去理解系统:

1. 阅读手册

理解系统的要素就是阅读手册.和我爸爸的评论相反,应该先阅读手册,然后去尝试各种方案.当你买了一个新东西时,自带的手册告诉你期望你做什么,系统会怎么响应你的操作.你需要从头到尾的读一边,以确保理解了它,这样你才能得到你想要的结果

如果你是一个正在调试你们公司自己生产的一个产品,你需要阅读你们内部的文档.你们的工程师设计它是用来做什么的?阅读功能规格说明书.阅读各种设计文档,学习时序图,状态机等各种图表,学习代码和注解.

需要注意的是,没必要完全相信这些信息.手册可能是错误的,很多难于调试的问题都源于此.但是,你仍然需要知道他们认为他们设计了一个什么东西.

实例:

我们正在调试一个用汇编编写的一个嵌入式固件程序,这意味这我们要直接和处理器的寄存器打交道.我们发现在一个地方,B寄存器的内容被破坏了.我们缩小范围,最终将问题定位在一个调用的子函数中.当我们查看那个函数时,在函数头部发现有一个注解说,这个函数会破坏B寄存器的数据,请修改这个bug(其实添加注解的人完全可以很容易的修改这个问题,先保存最后回复就行了,但是天知道他依然只留下一段注解的理由).

理解系统还有一个好处就是你修复bug的时候可以确保没有改变其他部分的行为.

2.从头到尾阅读一切可以阅读的东西

没有完整的阅读系统的手册就开着手调试该系统,这是很常见的一种情况.他们跳着阅读那些他们认为比较重要的部分,但是有可能恰好你跳过的那部分包含了程序出错的线索.我调试那个阀门控制系统到半夜一点就是一个惨痛的教训.

编程手册和API接口可能很厚又枯燥无味,但是你必须硬着头皮去真正的理解他们.往往是你自以为掌握的那个函数耗你调试无数个日夜,你忽略的那部分原理图设计恰好是噪声的来源.数据手册上模糊不清的那一行线是时序的关键.俗话说,人点背了,和凉水都塞牙,吃饭都可以噎死.

实例:

我们已经构建了几个版本的通讯板,有些上面有三个电话模块,有些上面有四个.在我们引入四路电话板的时候,三路电话板工作的已经很稳定了.所以我们没有给予四路电话板全面的内侧,因为我们认为仅仅是在三路电话上多增加了一路而已.

四路电话板在高温的时候罢工了.我们迅速的在实验室里进行了模拟,发现在高温的情况下一个主要的处理器崩溃了.这通常意味这程序存储器有问题,然后我们立马做测试,发现那个存储器在回读的时候数据不对.我们好奇,为什么三路板没有遇到这个问题.

硬件工程师看了这些板子,注意到四路板上使用了一个和三路板不同的存储芯片.但是,硬件工程师浏览了芯片手册,证实了他们同样的高效,拥有同样的读写时序,和处理器配合的时序也正确.

我通读了整个芯片手册,发现那个不同型号的存储芯片上定义了一个参数:在访问芯片之前你需要等待多久.

这个时间很短,似乎也是无关紧要的. 如果计算两种芯片等待时间的差值似乎更不重要了.但是处理器设计时没有考虑到这点要求,它不符合任何一个芯片的手册.所以它竟在在稍慢一点的芯片上失败,但是迟早也会出现在那个稍快一点的芯片上.我们修正了这一个问题.

应用笔记和实现指南提供了非常丰富的信息,他们不仅告诉我们他们是怎么工作的,也告诉我们人们曾经遇到过的问题.那些常见的错误是极其宝贵的信息,哪怕你只犯过不常见的错误.

参考设计和示例程序只是告诉你使用该产品的一种方式,有时这是你可以获得的唯一文档.但是你必须小心的看待这些设计和程序.因为这些东西都是由一批仅仅知道他们的产品,但是不遵守良好实践设计原则或者不为真实应用设计的人设计的.最常见的情况就是不考虑错误恢复.不要抄袭这些设计,如果现在你发现不了bug,将来你肯定会发现问题.有时,即使最好的参考设计也不可能满足你特定应用的需求.我抄袭我兄弟的设计就是一个活生生的例子.

<未完待续>