实时嵌入式系统软件调试问题分析

　　例如，假设一个设备必须在向其发任何指令前就完成初始化。编译器可能会移动指令位置，以便改善性能。这可能会造成设备的故障。如果你的设备驱动器调试后的版本是可行的，而采用经过优化的版本时会出现故障，那么你会想查看设备的初始化中是否有被移动的指令。你可能不得不采用恰当的编译器指南以便指导编译器不去对每条基本函数执行这样的优化，而不至于损失性能。

　　有时，将代码从一个架构移植到另一种架构上，也会带来某种数据类型上的问题。例如，一种架构内的整数可能是32 bit的，而其它的架构中可能是48 bit或者64 bit的。这可能会导致数据的失效或者被截断。

　　异常所带来的问题

　　如果异常是与程序的执行相同步的，则这往往是一种不当的操作的结果，例如零作为除数所造成的异常。某些异常则是架构所特有的。处理异常的最佳方法是采用缺省的异常处理器，并在出现异常时检查异常出现的环境。异常所处的环境背景是寄存器量值的集合，包括状态寄存器。大多数架构将拥有一个指令地址寄存器，用来保存造成问题的指令地址。在多数情况下，要知道一个异常是如何发生的并不难，但是，是何种指令路径可以隔离出这一失效，则是调试时棘手的地方。有些架构支持跟踪，即让你可以看到程序顺序执行的指令的历史。这将给出造成异常的指令顺序的某些细节信息。内存和寄存器讹误则是造成异常及程序逻辑错误的主要原因。通过细致检查造成异常的内存指向或者寄存器，将可以缩小问题的范围。

　　不能执行错误检验的代码会造成内存的讹误

　　由于性能方面的原因，开发商可能会放弃对错误的检查。跳过错误检查将让内存泄漏等事件无法为人所知，而最终导致内存讹误。例如，如果malloc()出现故障，而由于返回的值并未得到检验，则开发商将开始覆盖在内存的地址0x0地址所写入的量值，在很多嵌入式系统中，这则是一个有效的内存区域。一个技巧是，让某些地址0x0处的内存控制，以便排查出任何一种潜在的讹误。某些处理器架构就容许应用监测数据总线的活动，从而能抓住相应事件。

　　探寻架构特有的功能:

　　大多数嵌入式处理器都支持某种层次上的调试功能。内置的跟踪单元就是一种得到硬件支持的跟踪机制。例如，ADI公司的Blackfin处理器系列就具有硬件跟踪单元，它可以跟踪至少16路的时序控制器的访问。当硬件跟踪缓冲器充满后，就会产生跟踪异常。使用这种跟踪单元后，人们可以构建出完整的执行路径。所提供的跟踪输出来自于一种可以免费提供的工具(http://www.blackfin.org/) ，它可以构造完整的执行路径。

　　观察点：

　　观察点可以让你监测特定的内存位置或者内存块区正在被更改时出现的情况。观察点可以监测内部的数据总线传送，如果在观察点寄存器中，发现任何匹配的对象，则让处理器暂停。如果一个特定内存位置不断出现讹误，则观察点就非常有用。对内存块区进行观察以查看是否有任何正在损毁存储器数据的恶意代码。

　　大多数当前的调试环境都容许对内存和寄存器的内容进行修改。有时，修改寄存器的内容，可以让我们洞察何处出现了故障。例如，通过更改程序计数器，你可以迫使程序在特定函数出现时恢复执行。必须谨慎地对恰当的寄存器设定恰当的量值，具体方式则取决于处理器C函数的运行时间模型。另外一个有用的寄存器是IMASK，如果你正在调试任何一种实时操作系统，则调试(分步深入时)进程中任何时刻都会出现中断。由于调试后的代码不一定处于关键区，你可能几乎时时刻刻都要访问中断的例程。你可能无法屏蔽中断，因为它们让你的系统完成设定，并运行起来。例如，任何系统中的定时器的中断都可能会被触发。更好的方法是对IMASK寄存器进行编辑，将所有的中断都屏蔽掉，直到你调试完代码为止。

　　结论：

　　总之，由于调试是开发过程的最后步骤，因此它将对产品上市时间造成直接的影响。调试本身也是难以调度的，因为所发现的问题在复杂性和可避免性方面都大相径庭，上面所讨论的是一些在嵌入式系统开发期间常见的问题。这些调试技巧和提示旨在着重强调节省时间，因此在开发复杂的嵌入式系统时，应用现代的开发工具和拥有丰富调试功能的处理器能够改善投资收益。