通过对真实案例的学习和对专业工具（例如逻辑分析仪、JTAG调试器和性能分析仪）的广泛研究，本书提出了调试实时系统的实践方法。它遵循嵌入式系统的传统设计生命周期原理，指出了哪里会导致错误，进一步阐述如何在将来的设计中发现和避免错误。它还研究了应用程序性能监控、单个程序运行跟踪记录以及多任务OS中单独运行应用的其它的调试和控制方法。

为什么要写一本有关实时系统调试的书？我很高兴你能如此发问。有关实时系统或嵌入式系统调试已经有不少文章，但是据我所知，这些文章中的内容并没有被集结成册。
经过多年的嵌入式系统设计教学，我得出了这样的结论：我们作为教师是失败的。因为尽管我们的学生能够用汇编语言、C、C 、C#、某种特定Arduino语言或者Verilog编写程序并能编译编写好的程序，但是在面对突发问题时这是不可避免的，学生们仍然无法分析问题、按照系统化方式锁定问题原因以及查找和修正错误之处。我希望在本书中解决这些问题。
我注意到了学生们使用所谓霰弹测试方式，这令我非常沮丧。该方式指一次性进行大量修改，然后指望好事降临。甚至更令人不安的是，学生们会放弃他们的代码或者原型系统，全部从头再来，祈祷这样能解决问题，而不是试着发现和修复问题。
你可能会假设，当今天的学生变身为明天的工程师并且全身心投入产品设计时，他们就已经具备以高效的方式进行相关工作所必需的调试技术。我已经认识到这个假设难以成真。
在成为大学教师之前，我在公司工作，为嵌入式系统设计师构建设计和调试工具。我主要负责设计，并带领团队设计逻辑分析仪、在线仿真器和性能分析工具。在许多情况下，我还要设计复杂的设备以解决复杂的问题。仅仅学习并熟练掌握这些设备中的一种就已经很累了，许多工程师并不想为此花费大量时间。
也许你也是这么想的。你是否分析过这种投入产出比：是先花时间浏览一大堆手册再上手，还是直接上手并祈祷一切顺利？我曾经共事过的睿智的工程师John Hansen有过这样的言论这被人们称为汉森定律（Hansens Law）：
如果客户不知道如何去使用一项功能，那么这个功能就是不存在的。
因此，作为这些复杂而昂贵的调试工具的供应商，我们当然应负主要责任。我们无法有效地将技术转移给用户，让用户能够充分利用工具的强大功能来解决问题。
这里再举一个例子。我清楚地记得这个例子，因为它让我以一种全新的方式来看待技术以及技术转移。我们将在后文中继续讨论这个问题，但现在是介绍这个问题的好时机，这个问题与逻辑分析仪有关。多年来，逻辑分析仪已经成为实时系统分析的主要工具。有证据表明，其主导地位可能正在改变，但现在，我们假设逻辑分析仪仍然占据着突出的位置。
假设你正在调试一个复杂的、具有多优先级任务并发运行的实时系统，那么你就无法通过代码让处理器停止并执行单步运行。而许多优秀的调试器都是任务感知的，因此它们可以在不阻止其他任务全速运行的情况下，单独执行特定任务。
逻辑分析仪位于处理器（或者多个处理器）和系统的其他部分之间，并且实时记录处理器输出的每个地址位、数据位和状态位的状态，然后将其实时输入到处理器。一旦缓存区或者记录存储器存满，工程师之后就可以通过它进行跟踪，并观察在感兴趣的时间段内到底发生了什么。
但是如何定义感兴趣的时间段呢？你的存储缓冲区并不是无限大的，并且1s内处理器会完成数千万个甚至数亿个总线周期的运行。这就是逻辑分析仪作为一种工具的高光时刻。用户可以通过代码定义一系列事件，这非常类似于有限状态机中的一系列状态。在一些逻辑分析仪中，这些状态可以用工程师熟悉的高级C 代码来定义。
如果用户获取到这一系列正确定义的状态，逻辑分析仪将在代码序列中恰当的时间点触发（捕捉）跟踪，以显示何处出错。这就是有趣之处。在20世纪90年代中期，HP（现在是Keysight）逻辑分析仪的跟踪缓冲区相当小，但状态机非常复杂。当时的设计哲学就是用户不需要大的跟踪缓冲区，因为他们可以准确地定位问题。实际上，逻辑分析仪的状态机有8级。这里有个使用示例，如图1所示。
图1　逻辑分析仪多级触发系统示例
这个例子有3级，对于状态定义或可能运行的循环次数，每一级都有许多选项。我们发现，客户很少尝试设置超过2级的触发条件。他们不喜欢这个产品的原因是它的跟踪
缓冲区太小（5000个状态）。他们更喜欢使用深内存的简单触发，而不是浅内存的复杂触发。这与我们每次进行的客户回访是相当一致的。
重点是什么？与我们交谈的工程师们没有使用逻辑分析仪强大的触发能力，而是选择了难度小的方式。他们宁愿手动浏览冗长的跟踪列表以找到感兴趣的事件，也不去学习如何设置复杂的触发条件。换句话说，要权衡是使用一个复杂的工具，还是使用一个功能较弱但更容易使用的工具。
你可能会说工程师们很懒，但是我不这么认为。我相信，如果我们工具设计师可以发明一种正在尝试解决困难的调试问题的工程师与工具本身之间的更直观、更友好的用户接口，使工程师每次都能获取解决方案，那么他的调试能力也会不断提高。
为什么我要举这个例子呢？我想在本书一开始就提到它，因为调试实时系统通常非常困难，工程师需要使用复杂的工具，以便及时将高质量的产品推向市场。如果本书有助于学习如何使用工具，或者能促使读者更深入地研究用户手册，那么本书就达到了目的。
本书初的目标读者是学生，不仅是那些想要进入嵌入式系统设计领域的学生，而且是所有希望在设计调试中提高自己技能的电气工程、计算机科学或计算机工程的学生。他们可以在工作面试时随意地提到，自己已经付出了一些努力，不仅能做项目，还能够实现没有缺陷的项目。此外，他们还可以向面试官表示，他们进入就业市场时所拥有的技能比同期毕业生所拥有的要多。
对于已经是从业者而且想磨炼技能的、有经验的工程师而言，我希望本书会提供一个他们可能还不知道的工具与技术的路线图，或者提供更有效的方法来解决突然出现在工作中的问题。
在研究和编写本书的过程中，我发现对特定类别错误而言，应用笔记和白皮书是好的信息来源。我自己写过很多这样的文章，因此对这些信息的质量很有信心。
如果你仔细想想，这是显而易见的。随着技术的进步，公司会不断地调查其客户群以查找总是出现的设计和调试方面的问题。这些客户的问题是创建工具的驱动力，这些工具将解决问题或者至少能指出问题的根源。
一旦发明了这种工具，公司必须向客户解释它的潜在价值，所以会在会议上发表演讲，在行业出版物上发表技术文章，推出与问题关联的应用笔记，以及问题、工具和解决方案相关的资源，以期得到工程师的认可并通过他们向高层管理人员证明采购的合理性。
这些文章虽然明显是服务于发表文章的公司的，但依然是有价值的资源，它们能向工程师提供好的、的实用信息。对我来说，这些资源是本书的主要资料来源。
我们将从检查调试问题本身着手。导致调试问题如此独特的实时系统的本质是什么？关于这个问题，你可能会说：实时性啊。但这只是问题的一部分。对大量的嵌入式系统而言，确定的硬件、可编程的硬件、固件、操作系统和应用软件都可能是独特的，或者至少大部分设计是独特的。
甚至随着产品的技术进步还算不上技术革命，就会有许多新元素必须被集成到整个设计中。因此，不仅仅是实时或者非实时的问题，还有系统中变量的数量，以及系统必须实时运行等问题。
在审视问题之后，我们会将注意力转到如何调试硬件和软件的整体策略上来。我们将着眼于实践和通用策略。此外，考虑可测试性问题也很有用，因为调试那些没有把调试作为首要设计的系统是一个挑战。
从策略上，我们将把注意力转向工具和技术。我们将着眼于一些基本问题，并寻求方法来解决。
接下来，我们将介绍芯片制造商提供片上调试和性能资源的形式，以帮助客户将新设计推向市场。
本书的后一部分将涵盖串行协议，以及如何调试它们。按照领域内一些专家的观点，越来越多的调试问题与串行数据传输相关，与经典调试技术相关的问题越来越少了。
我尽力让本书通俗易懂，不那么学究气。我将很多个人的逸事写进书中，因为它们可以帮助表达观点，并且读起来很有趣，写起来也很有趣。这个方法我是从Bob Pease的经典著作Troubleshooting Analog Circuits[1]中学到的。许多高级工程师都知道Bob在Electronic Design Magazine上的专栏Whats all this…。
他的书和这些专栏都是经典的资料，我在本书中也借用了他的谈话风格。顺便说一下，我喜欢的Whats all this…专栏的内容是他对那些正在使用的昂贵扬声器电缆的分析，证明它们与简单的电灯线相比更具音频优势。Bob的分析很严格，同时具有阅读的乐趣和教育性。更重要的是，他很好地让音频优越性跌至谷底。
另外，我并没有严格地将主题材料限定到该主题相关章节中。你会发现一些例子可能会出现在不同的章节。这是特意构思的，而不是我短暂失忆所致。这个做法来自教学实践。我经常反复回顾材料，以便把它放在不同的章节内容中，而不是简单地讲讲就过去了。因此，如果在关于常见软件缺陷的章节中，你看到关于常见的实时操作系统（RTOS）错误的讨论，然后发现它在调试实时操作系统的章节中再次出现，不要说我没有警告过你。

译者序
前言
第1章　问题在何处　/ 1
参考文献　/ 8
第2章　系统化的调试方法　/ 9
2.1　调试的六个阶段　/ 9
2.1.1　谁有故障　/ 12
2.1.2　我遇到过的一个缺陷　/ 12
2.2　参考文献　/ 22
第3章　嵌入式软件调试的实践　/ 23
3.1　引言　/ 23
3.2　造成嵌入式系统与众
　　 不同的原因　/ 24
3.2.1　嵌入式系统专门用于特定
　　　　　　的任务，而PC是通用的
　　　　　　计算平台　/ 24
3.2.2　软件失效在嵌入式系统中
　　　　　　造成的影响要比在桌面系
　　　　　　统中严重得多　/ 24
3.2.3　嵌入式系统具有实时性约束　/ 25
3.2.4　嵌入式系统可被各式各样
　　　　　　的处理器以及处理器架构
　　　　　　支持　/ 26
3.2.5　嵌入式系统通常对成本
　　　　　　非常敏感　/ 26
3.2.6　嵌入式系统具有功耗限制　/ 27
3.2.7　嵌入式系统必须能在
　　　　　　环境下工作　/ 27
3.2.8　嵌入式系统的资源要比桌面
　　　　　　系统少得多　/ 27
3.2.9　嵌入式微处理器通常具有
　　　　　　专用调试电路　/ 27
3.2.10　如果嵌入式系统用到了操作
　　　　　　　系统，那么它所用的很可能
　　　　　　　是实时操作系统　/ 28
3.3　嵌入式系统调试的实践　/ 28
3.4　通用软件调试实践　/ 32
3.5　嵌入式软件调试实践　/ 36
3.6　内存泄漏　/ 37
3.7　时钟抖动　/ 39
3.8　优先级反转　/ 40
3.9　栈溢出　/ 40
3.10　本章小结　/ 41
3.11　拓展读物　/ 42
3.12　参考文献　/ 43
第4章　调试嵌入式硬件的实践　/ 44
4.1　概述　/ 44
4.2　硬件调试过程　/ 44
4.3　设计评审　/ 45
4.4　测试计划　/ 47
4.5　可测试性设计　/ 49
4.6　构建流程　/ 50
4.7　了解你的工具　/ 53
4.8　微处理器设计实践　/ 57
4.8.1　引言　/ 57
4.8.2　可测试性设计　/ 57
4.8.3　考虑PCB问题　/ 58
4.9　本章小结　/ 63
4.10　拓展读物　/ 64
4.11　参考文献　/ 64
第5章　嵌入式设计与调试工具概览　/ 66
5.1　概述　/ 66
5.2　调试器　/ 66
5.3　软硬件协同验证　/ 69
5.4　ROM仿真器　/ 73
5.5　逻辑分析仪　/ 77
5.6　逻辑分析仪的优势　/ 84
5.7　逻辑分析仪的问题　/ 84
5.8　在线仿真器　/ 85
5.9　拓展读物　/ 89
5.10　参考文献　/ 89
第6章　硬件/软件集成阶段　/ 90
6.1　概述　/ 90
6.2　硬件/软件集成图　/ 90
6.3　非标准硬盘驱动器接口的案例　/ 91
6.4　向量显示器的后关头　/ 92
6.5　性能差劲的仿真器卡笼　/ 92
6.6　功能蠕变和大客户　/ 93
6.7　参考文献　/ 108
第7章　片上调试资源　/ 110
7.1　概述　/ 110
7.2　后台调试模式　/ 111
7.3　JTAG　/ 112
7.4　MIPS EJTAG　/ 115
7.5　本章小结　/ 116
7.6　参考文献　/ 118
第8章　片上系统　/ 119
8.1　概述　/ 119
8.2　现场可编程门阵列　/ 120
8.3　虚拟化　/ 126
8.4　本章小结　/ 129
8.5　拓展读物　/ 130
8.6　参考文献　/ 130
第9章　隔离缺陷的测试方法　/ 131
9.1　概述　/ 131
9.2　查找问题的障碍　/ 131
9.3　临时应急　/ 132
9.4　寻求帮助　/ 132
9.5　故障隔离　/ 133
9.5.1　了解你的工具　/ 134
9.5.2　理解你的设计　/ 136
9.6　与性能相关的故障　/ 137
9.7　可复现故障　/ 137
9.8　间歇性故障　/ 138
9.9　合规故障　/ 141
9.10　扩频振荡器　/ 142
9.11　热故障　/ 144
9.12　机械问题　/ 146
9.13　与供电相关的故障　/ 147
9.14　本章小结　/ 149
9.15　参考文献　/ 151
第10章　调试实时操作系统　/ 152
10.1　概述　/ 152
10.2　RTOS中的缺陷　/ 152
10.3　同步问题　/ 153
10.4　内存崩溃　/ 154
10.5　与中断相关的问题　/ 155
10.6　意想不到的编译器优化　/ 157
10.7　异常　/ 157
10.8　RTOS感知工具：一个示例　/ 159
10.9　参考文献　/ 163
第11章　串行通信系统　/ 164
11.1　引言　/ 164
11.2　RS-232　/ 165
11.3　错误的COM端口分配　/ 165
11.4　不正确的电缆引脚　/ 166
11.5　错误的波特率（时钟频率）　/ 166
11.6　不正确的流控　/ 167
11.7　I2C和SMBus协议　/ 168
11.8　SPI协议　/ 171
11.9　工具　/ 174
11.10　控制器局域网络（CAN总线）　/ 174
11.11　本章小结　/ 175
11.12　拓展读物　/ 175
11.13　参考文献　/ 175
第12章　存储器