为嵌入式应用构建黑盒子

有人认为要是您在凌晨三点最终发现了困扰您多日可又一直找不到的程序错误，那真是再没有比这更高兴的编程经历了。请注意，我们的开心源于找到了漏洞，而不是解决问题。这是因为您一旦真正了解了为什么会存在程序错误，那么纠正错误就是一件小事了。如果您过去用了错误的方法，那么现在就要用正确方法；如果您的输入有误，现在就可以进行整理；如果您假定系统有错误，那么就改正它，并认真在整个代码中进行相应修改。

当然，当英雄的时候很风光，不过找程序错误并不是程序员真正的满意源。请设想您要在花园中挖一道沟，并在其中铺设喷水装置管线。如果您遇到一块石头挡住去路，那么我们可在石头四周挖土，让石头松动移位，这就解决了问题。如果石头太大，那么重新设计布局也很有意思，这样您就可以完全避开石头。不过移开石头的快乐并不是挖沟的目的所在。在认真想想，您的目的其实也不是安装喷水装置。您的目标是为您自己或为了让您的配偶高兴而建设美丽的花园。

编程的情况与之类似。实时系统故障排除的过程可能遇到很困难的程序错误。经验丰富的程序员知道不会有太多工具帮忙找到并了解程序错误。不幸的是，随着系统变得越发复杂，传统的故障排除工具不再像其过去那样有效。我们不妨设想开发实时视频处理设备（如摄像机）的情况。即便您采购到速度足够快的逻辑分析器，具备足够的通道来观察媒体处理器，但由于大部分重要工作都发生在专用引擎和内部高速缓存及存储器中，您还是难以对其进行跟踪。您对处理器的可视程度是有限的。即便您为处理器找到了电路内仿真器 (ICE)，但要想在摄像机等小型便携式设备中安放探针插件仍是不可能的。

上述所有原因解释了许多处理器厂商已经开始在芯片上直接集成调试功能的原因。您可利用原型规划出您的设计，这样您就可以访问设备的各种组件；但是，仍会有一系列实时问题存在--也就是那些您的客户会遇到而您在实验室中又难以再现的问题，您只能在生产设备中才能进行观察。

在JTAG 基础上工作

集成调试外设已经推出一段时间了。举例来说，JTAG 仿真为观察处理器的内部实现了伪实时可视性，这就使开发人员能够读写存储器或寄存器，抑或控制/监控处理器的执行。但是，JTAG 的主要问题在于，它是用正在被测试的处理器进行上述操作的。即便像察看寄存器集或单个存储器地址这样的简单操作也会影响认真优化过的管道流程，感染缓存，破坏脆弱的实时定时，屏蔽甚至模拟错误，这就会大幅改变处理器的执行。

新系列处理器提供了更先进的调试外设，可为处理器内部进行的核心操作提供更高的可视性，从而增强了 JTAG 功能。外设不再需要接受测试的内核来执行额外的工作，而是自己与内核并行执行，通常可以访问全部系统寄存器、存储器，甚至可以控制处理器自身的执行。这样，我们就在不打扰操作的情况下获得了深入内核的可视性，乃至能够监控代码高度优化过的部分。

毫无疑问，软件开发人员最可怕的噩梦就是不断出现程序错误。不管出于何种原因，只要客户使用就出问题，但在实验室中却无法重复问题。开发人员常常甚至不能进行事后的调查分析重建崩溃情况，因为存储器内容已经删除，数据也被破坏。开发人员切实需要的是类似飞机上安装的"黑盒子"，它能够在崩溃后幸存下来，记录下所有所需数据，并将时钟拨回原来位置。随着调试外设的最新发展，这种黑盒子现在已经成为可能。

一些实现黑盒子常见的调试外设可做到实时数据交换、复杂触发、多处理器支持、时间关键性中断屏蔽、自动跟踪等，并具备能够准确而细致地重建设备任何时间点状态的工具。

实时数据交换

一个简单而非常实用的工具就是能够读取或写入存储器，同时又不会导致被测试的处理器停止或中断其操作。在您放置断点时，是用断点操作码替代一个代码字节。断点很复杂时，不具干扰性的存储器存取非常有用；如果您希望在中断前执行x次代码，或者特定的变量为具体值或在某一范围内（监视点）时，那么这就非常有用了。如果处理器必须停下操作才能进行每次比较，那么不仅执行每次比较要占用循环，而且比较本身也会影响指令和存储器缓存。如果断点在一个时间关键性的优化环路中，那么其造成的缓存效率低下就会导致代码无法满足实时期限的要求，而这也正是它与有效代码的差距所在。如果监视点和其他系统组件争用存储器总线的话，那么就会造成更大干扰。

无干扰性存储器存取可实现更高效的断点。不用断点操作码，而是由调试外设来监控程序计数器并与处理器并行执行比较，同时不致影响缓存或程序定时。使用断点操作码的另一问题是指令缓存反映的是断点操作码而不是被替代的字节。当您恢复执行您同断点操作码所交换的字节时，整个缓存会因此而失效。由于监视点在寄存器或内部存储器上，调试外设会等待存储器总线再次变得可用，抑或也可具备其自己的专用总线。在上述两种情况中，外设都不会与测试中的系统发生竞争。

还要考虑采用反选监视点的情况。假设本地变量破坏的情况。我们设置标准监视点在每次变量修改时触发中断，这就让您必须察看所有有效的修改才能找到导致错误的因素。如果反选监视点，也就是说只跟踪或触发发生在代码功能外的修改，那么您就能大幅减少必须亲自评估的修改数量，这就提高了您找到出错修改的速度。

实时数据交换对于微调算法也是非常实用的。举例来说，根据特定的一组扬声器调节音频算法，或根据图像传感器调节视频算法，这比重新编译代码并重新下载要节约大量时间。您还可以手动破坏数据流或代码，抑或用已知有问题的值预先载入寄存器和存储器启动会话，从而测试代码的稳健性。举例而言，在视频应用中，您可以破坏一段进入的视频流，看看编码器或解码器如何应付违反预计格式的数据。同时改变大块数据直接而方便：将数据分组成单个对象中，由指针引用，改变对象的临时实例，随后改变指针，以刚输入的数据引用临时实例。