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

　　前言

    在嵌入式技术飞速发展的今天，嵌入式产品已经出现在社会的各个领域，包括航空、航 天、通信、军事、仪表、工业控制及家庭消费等。每年要消耗掉30 亿颗嵌入式微处理器， 嵌入式系统带来的工业年产值已经超过了1 万亿美元。嵌入式系统软件的调试技术一直是一种困难而富有挑战性的技术，现在的微处理器在速度和复杂程度上都发展得很快，在一个典型的嵌入式系统里面不仅有高性能微处理器、存储器和各种不同的总线，还有实时操作系统， 复杂的应用程序等。这给嵌入式软件，固件设计人员在设计过程中带来了极大难度，对调试工具的开发带来了很大的冲击。高速而又复杂的微处理器加上更长的软件使得开发一个新系统十分困难，一些传统的仿真工具无法满足全部调试要求。本文将讨论常见的调试问题以及预防和检查这些故障问题的一些方法。

　　在一般情况下，我们把嵌入式应用代码的调试流程分为两类。类调试流程是回答 “我的代码现在执行到哪里？” 的问题。当开发商依靠打印语句或者LED的闪烁来指示应用程序执行到某个节点的调试方法时，往往就属于这种情形。如果开发工具支持这种调试方法，可以沿着应用应当程序应当执行的路径插入断点。第二类调试流程是帮助回答“我看到的这一数值是从哪里来的？”这一问题。在这种情况下，人们往往依靠寄存器显示窗口观察变量信息、处理器内存的内容。人们还可以尝试单步执行，并且观察所有这些数据窗口以了解某个寄存器状态何时出现错误，内存位置何时得到错误的数据，抑或指针何时出现了误用。

　　当开发商写完全部代码后，如果无需了解网络基础设施，也没有操作系统的任务调度需要考虑，那么就可以利用这些调试方法使一个应用程序运行起来。然而，现在的情况并非如此。嵌入式处理器以超过600 MHz的速度运行，并且拥有可支持Ethernet和USB等协议的嵌入式外设，它们支持功能齐备的操作系统，例如uClinux，而且这些操作系统所调度的各种应用程序是由数千行代码构成。使用打印语句和利用LED来调试是不现实的，因为现在常常有如此之多的功能在执行是不可能的，或者它们会影响标准I/O口，从而造成处理器性能大幅度下降。

　　也可能发生这样的情况：处理器的工作速度是如此之快，以至于LED的亮灭速度会快到人眼无法察觉。我们看到的将会是LED灯一直是亮的。另外现代的嵌入式系统通常支持断点的设定，但是伴随这些处理器所运行的代码数量，使得这种类型的断点调试难以驾驭。中断和多线程系统在代码的任何一点上设置一个断点，可能都无法指示系统的正确状态。由于断点设置在物理内存的某个地址上，索引不必了解线程的状态。如果使用寄存器显示方法，那么局部变量窗口和内存窗口都将有助于隔离出所载入的不恰当的量值，但是，由于这些是静态化的工具，不能给出有意义的运行中的调试信息，其适用性也常常很有限。所以我们需要更好的调试方法来避免以上问题，当然首先让我们看看实时嵌入式系统软件常见的调试问题。

　　实时嵌入式系统软件常见的调试问题可以大致划分为如下几类：

　　1  同步问题

　　2  逻辑问题

　　3  内存和寄存器讹误（corruption）

　　4  与中断相关的问题

　　5  硬件配置问题

　　6  硬软件配合问题

　　7  实时软件问题

　　8  异常情况

　　同步问题

　　不管在任何系统中，只要有多串序线程或者进程都在运行，而且是异步共享数据，则系统必然存在同步问题。对于共享数据的全部操作必须是原子化的，也就是说，只有在一个线程或者进程完成对数据的操作后，其它的线程才能对数据进行操作。

　　以图1为例，线程A和线程B对共享变量“counter”进行操作，A让counter 增加，而B则让counter减少。下方示出了线程A的counter++和线程B counter-的汇编代码。假设线程B的优先级要高于线程A，而线程A目前正在运行，则线程B将被阻止。

　　举例来说，假设初始的计数值是2，而线程A是执行线程。则线程A读入计数值，并送入一个寄存器，在使其增加一个增量后，再将其写回计数器变量上。

　　在可抢先的多线程系统中，高优先级的线程的执行可以抢先于低优先级的线程。例如，假定线程A执行Reg1 = Reg1+1指令后，一个事件唤醒线程B。此时，Reg1储存量值3。现在线程B被唤醒（正如蓝线所标示的那样），并读入计数器的量值2（它尚未被线程A刷新）并将其量值减小到1。正如棕色的线所显示的那样，经过一段时间，线程A恢复运行，将Reg1写入计数器中，而该计数器的储存量值为3。在这个过程中，线程B的减量操作结果被丢弃。计数器存储的量值变为2，即线程A进行增量后，线程B又进行了减量操作。被窜改的链接表则是另一个例子。如果数据被一个线程和中断例程共享，则也会出现上面的问题，因为中断的执行与线程的执行之间是异步关系。

　　同步化方面的问题常常是很难进行调试的，因为它们取决于时序，是随着软件对数据的操作而随机出现的。幸运的是，这些问题可以通过恰当地保护任何共享数据来避免。大多数的实时操作系统可以提供同步化原语。开发商可以使用适当的机制来保护共享数据，而不至于影响系统的性能。如果数据在多个线程之间共享，则开发商将有如下的选择：

　　a. 关闭调度器以便当前的线程永远不会被其它线程抢先。（无调度区）

　　b. 使用信号两（Semaphore）或者互斥信号量（Mutex）来保护共享数据。

　　c. 利用关键区域来进行保护，即屏蔽所有的中断。

　　开发商必须从性能出发来选择恰当的技术选项。关闭调度器，将防止任何一种环境的切换，从而使得现在的线程能继续执行，直到调度器重新打开为止。这种方法有一个负面的影响：它将阻止任何准备好运行的高优先级的线程。这一现象被称为优先级倒置。将中断关闭是安全的方法，对于执行时间短的情形来说是理想选择。于是，差情况的中断延迟就是所有未发生中断的持续时间的总和。在硬实时系统中，一般来说，一个中断功能可以被关闭的时间存在上限。

　　其实对于调试还有一个小窍门，如果共享的数据被破坏，则编程者就应当首先检查出任何一种多个线程或者中断对共享数据同时进行的操作。如果线程和中断共享了数据，那么在线程代码中必须将中断关闭。如果数据在多个中断例程之间共享的话，则中断也应当被关闭，因为高优先级的中断可以抢先于低优先级的中断。

　　在多线程的系统中，高优先级的线程可以抢在低优先级的线程之前执行。因此，如果数据在多个线程间共享的话，则必须采用某种恰当的机制来保护被共享的数据。

　　同步化问题的另一方面则与线程优先级的不恰当的分配有关。应当确保系统的初始化线程在引导时间内就启动，并在生成其它的优先级更高的线程之前，完成整个系统的初始化。例如，如果一个用于配置一个器件的低优先级现场被一个使用该设备的高优先级的线程抢先后，配置可能会完成，并可能会造成设备的故障。为了避免这种情形，开发商应当使用操作系统所支持的信号量或者其它同步化的原语。

　　逻辑问题

　　逻辑设计、编码错误或设计假设不正确都属于逻辑问题。这些问题常常很容易被硬件仿真器或软件调试程序发现并解决。逻辑问题通常占设计人员遇到的所有调试问题的80％，但是，解决这些问题通常仅需要占用20％的调试时间。查找逻辑问题比较简单，进行相关的修改则比较容易。其余20％的问题是由其它三类问题构成的，为查找和修改这些问题，可能会占用80％的调试时间。

　　内存和寄存器的数据讹误

　　大多数的嵌入式系统都采用了平面化的内存模式，也并没有内存管理单元（MMU），于是没有硬件支持的内存保护机制。即使采用能提供这种功能的处理器，也需要由开发商来实现对某些内存区域的保护。进程和线程将对其它进程和线程的内存空间有完全的访问权限。这可能会造成下面所描述的、各种类型的内存讹误问题。

　　堆栈溢出

　　运行时堆栈是在函数调用进程中所使用的一种暂存空间，用于存储局部变量。硬件寄存器指针（SP）将跟踪堆栈指针的地址。如果你在的语言中编程，如C语音，则编译器所生成的代码将使用与C语言运行时间模型相一致的堆栈。运行时间模式定义了变量是如何存储在堆栈中的以及编译器将如何使用堆栈。局部的变量被放置在当前的堆栈中。下面给出的例子描述了在堆栈上采用的某些关键性的内存。

　　当堆栈指针超出了其所指定的边界时，就会出现堆栈溢出。这将造成内存的讹误，并终造成系统的失效。在上述的实例中，如果总的堆栈内存区不足以容纳所有的局部变量，堆栈溢出就会发生。

　　调试的一个技巧就是，如果你担心溢出，一个好的做法，就是将堆栈安排在内存边界上，这样，如果在调试过程中出现了溢出，则仿真器将触发一个硬件异常提示。

　　开发商可以采用的一个技巧是，如果你担心堆栈的溢出，你就应当考虑把它放在有效的内存的边界上。这样，当堆栈溢出时，设备将硬件异常，而不是造成其它内存空间的讹误。

　　在独立运行的应用中，运行时间堆栈可能就已经够用。然而，在使用任何一种实时操作系统时，每个线程和过程都将有自己的堆栈。考虑到性能方面的原因，大多数嵌入式实时操作系统的堆栈尺寸都是事先确定的，无法在运行中动态扩展。这意味着，如果针对特定的线程/进程所选用的堆栈尺寸不恰当的话，堆栈溢出就会发生。

　　如果应用大量使用局部变量（如阵列和大的结构），则将不得不按比例为其分配堆栈的空间。人们可以利用malloc（） 来分配内存，或者将其设置为静态的全局变量，具体是何种方法，则取决于实际应用。

　　有些实时操作系统可能会提供调试功能，例如保护位，以形成对堆栈溢出的防护。这些操作系统要么记录关于堆栈溢出的错误信息，要么提交一个异常，以便动态地增加堆栈。起码当前的大多数实时操作系统都能堆栈以及已经被线程和进程所采用的堆栈的情况。

　　在任何中断驱动的系统中，堆栈的分配方式都必须考虑到中断服务例程所采用的空间。如果中断例程的设计目标是使用当前的执行对象栈，则在这种情况下，每一个线程或进程所拥有的的堆栈尺寸都应大于或者等于执行对象所要求的堆栈尺寸加上所有中断例程累积起来所需要的的堆栈尺寸。

　　嵌入式系统开发商必须掌握各种应用链接库。例如，第三方的库可能会认定堆栈上为其提供了空间。

　　硬软件配合问题

　　调试这类问题比较困难，通常需要借助某种形式的物理跟踪工具。针对这类型问题，传统上可以选择逻辑分析仪作为数据跟踪工具，可以检查目标系统中硬件和软件的相互影响。例如，为什么一些指令会引起内存溢出，或者为什么在处理器的数据总线中，某种数据码流会导致串扰引起的错误信号。

　　中断服务例程代码编写时所出的问题

　　一般情况下，在嵌入式系统中，出于性能方面的考虑，中断服务例程是以汇编形式编写的。中断本质上是属于异步的，在应用程序执行中的任何时刻都有可能出现。汇编层次上的中断例程常见的问题，是寄存器的讹误。在中断服务例程中所采用的寄存器所存储的数据，在寄存器被使用之前都必须被保存，而在从中断服务例程返回之前，这些数据将被恢复。开发商必须了解状态寄存器的情况，而任何一种ALU的操作都会改变其状态。在这种情形中，ISR应该保存其状态并进行恢复，仿佛它是一个已被使用的寄存器一般。

　　如果中断例程是用C语言编写的，它们的开发也是为了使用当前的堆栈，则开发商就应该针对堆栈溢出情况进行防护，即每个线程都应该拥有足够多的堆栈，来满足中断或者嵌套的中断堆栈的要求。的做法，就是让中断例程的规模尽可能小，推迟处理过程，交给一个线程或者优先级较低的中断。在开发过程中，开发商可以在中断的开始和结束部分添加诊断功能，对基础的架构中的寄存器的状态进行比较。

　　中断嵌套可以让一个高优先级的中断抢先于低优先级的中断例程执行。开发商应该考虑到堆栈要求的峰值，并为其分配充足的空间（考虑差的情况，即你的系统中的每一个中断都被一个优先级更高的中断所抢先）。

　　而操作内存映射寄存器（MMR）时，人们常常采用在线汇编以改善性能。例如，你在屏蔽中断时，可能希望直接设定中断屏蔽寄存器（IMASK）而不是执行RTOS所提供的应用软件编程接口（API）。例如原子增加或减少操作常常是用汇编语言编写的。在C函数中，这些宏汇编可能会被调用，在这种情况下，编译器可能不了解在宏汇编中所使用的寄存器。因此这会导致寄存器的讹误。有些编译器具有汇编的扩展版，可以将关于这些函数的更多的信息传递给编译器，例如已被使用的寄存器、代码在内存中的位置等等。这将使得编译器可以生成恰当的代码。

　　有时，某些函数是以汇编语言编写的，将被C函数所调用。如果汇编代码并未按照C函数运行时间调用规范来编写，即按照编译器所要求的那样进行，则会导致参数传递（argument passing）无效和讹误。例如，C函数运行时间模型可以规定前两个参量必须通过寄存器R0和R1来传递，则汇编的实现方式就必须按照这种语法来编写。在另一种情况下，运行时间模型可能需要存储堆栈上的函数的返回地址。如果汇编的实现方法并不符合运行时间模型，则它可能会搅乱某些寄存器，并带来系统的故障。如果开发商使用混合模式的语言来避免这种类型的问题的话，开发商就必须清楚运行时间模型。

　　编译器

　　编译器的优化，即使实现了逻辑上的正确性，有时也仍然会造成故障。采用低水平的设备驱动器时，这一问题特别关键。重排指令是实现更高性能的常用方法，因为处理器常常支持单个周期内执行多条指令。因此，编译器将试图调度指令，使得所有的指令时间片都得到充分的利用，即使这意味着在寄存器使用前很久就载入数据，或者在数值被计算完毕后很久，也让内存保持载入的数据。请看附图，其中描述了这种内存的移动是如何发生的。

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

    编译器自动在指定的分支及函数出入口插入对特定内存区域的写指令（与gprof等profiling工具采用的手段类似），它们都是不通过缓存而直接向内存写的，这就能反映于芯片外总线从而被外接的逻辑分析仪记录，终由主机端的调试工具分析并结合符号表重构程序流。这种方法虽被广泛使用，但毕竟是干扰式的（intrusive），对系统性能也有影响。

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

　　实时软件问题

　　这类问题是难调试的问题，因为这样的问题仅在目标系统全速运行时发生，无法使用调试器配合仿真器进行单步调试。

　　异常所带来的问题

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

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

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

　　系统崩溃问题

　　嵌入式系统与非嵌入式系统（如PC或工作站）的区别在于，它们通常不能防止错误程序导致目标系统崩溃。PC或者工作站等提供了健壮的操作系统，它们提供各种机制，使系统与运行错误的应用程序分离，而嵌入式系统通常没有提供这样的机制。因此，当嵌入式系统中的软件崩溃时，常常导致整个系统失效，进而丢失对确定根本原因非常有用的任何信息。

　　探寻架构特有的功能

　　大多数嵌入式处理器都支持某种层次上的调试功能。内置的跟踪单元就是一种得到硬件支持的跟踪机制。例如，ADI公司的Blackfin处理器系列就具有硬件跟踪单元，它可以跟踪至少16路的时序控制器的访问。当硬件跟踪缓冲器充满后，就会产生跟踪异常。使用这种跟踪单元后，人们可以构建出完整的执行路径。所提供的跟踪输出来自于一种可以提供的工具（https://www.blackfin.org/） ，它可以构造完整的执行路径。是一个非常不错的工具，如果你还没相应的工具强力推荐这个。当然你有自己习惯的就不需要啦。仁者见仁智者见智，萝卜青菜各有所爱嘛。

　　观察点

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

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

　　结论

　　总的来说，调试都是作为开发的步骤，因此它将对产品上市时间造成直接的影响。就好比要某产品要出厂的检验时候合格一样，毕竟合格的物品人们才会要的，更不必说有些物品还是要自己用的，合格关至关重要的。调试本身也是难以调度的，因为所发现的问题在复杂性和可避免性方面都大相径庭，上面所讨论的是一些在嵌入式系统开发期间常见的问题。这些调试技巧和提示旨在着重强调节省时间，因此在开发复杂的嵌入式系统时，应用现代的开发工具和拥有丰富调试功能的处理器能够改善投资收益。在高速嵌入式软件调试过程中，由于系统速度和复杂度越来越高。只依靠仿真器，监控程序等工具不能很好的满足软件调试人员的要求。利用逻辑分析仪的软件调试功能，源代码支持和实时数据捕获功能，弥补软件调试器功能的局限性，将逻辑分析仪和传统软件调试工具结合起来，使软件调试人员能够从系统级的角度来考察嵌入式系统的运行情况，快速解决高速嵌入式软件中难以解决的问题。

    总之，处理器厂家提供集成于片内的调试电路为嵌入式系统开发提供各种非干扰式的调试手段早已是大势所趋。为了解决该领域标准化的需要，一些处理器厂家、工具开发公司和仪器制造商于1998年组成了Nexus 5001 Forum，这是一个旨在为嵌入式控制应用产生和定义嵌入式处理器调试接口标准的联合组织，以前的名称是Global Embedded Processor Debug Interface Standard Consortium（嵌入式处理器调试接口标准协会）。Nexus现在有24个成员单位，包括创始成员Motorola、Infineon Technologies、日立、ETAS和HP等公司。该组织首先处理的是汽车动力应用所需要的调试，现在已发展成为调试数据通信、无线系统和其他实时嵌入式应用的通用接口

　　嵌入式实时系统简介

　　实时系统（Real-time operating system,RTOS）的正确性不仅依耐系统计算的逻辑结果，还依赖于产生这个结果的时间。实时系统能够在指定或者确定的时间内完成系统功能和外部或内部、同步或异步时间做出响应的系统。因此实时系统应该在事先先定义的时间范围内识别和处理离散事件的能力；系统能够处理和储存控制系统所需要的大量数据。

　　RTOS是一个内核。典型的单片机程序在程序指针复位后，首先进行堆栈、中断、中断向量、定时器、串行口等接口设置、初始化数据存储区和显示内容，然后就来到了一个监测、等待或空循环，在这个循环中，CPU可以监视外设、响应中断或用户输入。 这段主程序可以看作是一个内核，内核负责系统的初始化和开放、调度其它任务，相当于C语言中的主函数。 RTOS就是这样的一个标准内核，包括了各种片上外设初始化和数据结构的格式化，不必、也不推荐用户再对硬件设备和资源进行直接操作，所有的硬件设置和资源访问都要通过RTOS。

　　.RTOS是一个平台。RTOS建立在单片机硬件系统之上，用户的一切开发工作都进行于其上，因此它可以称作是一个平台。采用RTOS的用户不必花大量时间学习硬件，和直接开发相比起点更高。 RTOS还是一个标准化的平台，它定义了每个应用任务和内核的接口，也促进了应用程序的标准化。应用程序标准化后便于软件的存档、交流、修改和扩展，为嵌入式软件开发的工程化创造了条件、减少开发管理工作量。嵌入式软件标准化推广到社会后，可以促进软件开发的分工，减少重复劳动，近来出现的建立于RTOS上的文件和通信协议库函数产品等就是实例。

　　嵌入式实时系统的特点有：1、时间约束性（实时系统的任务具有一定的时间约束（截止时间）。）；2、可预测性（可预测性是指系统能够对实时任务的执行时间进行判断，确定是否能够满足任务的时限要求。）；3、可靠性（大多数实时系统要求有较高的可靠性。）；4、与外部环境的交互作用性（实时系统通常运行在一定的环境下，外部环境是实时系统不可缺少的一个组成部分。）。

　　嵌入式实时系统可以分为2类：强实时系统（Hard Real-Time）：在航空航天、军事、核工业等一些关键领域中，应用时间需求应能够得到完全满足，否则就造成如飞机失事等重大地安全事故，造成重大地生命财产损失和生态破坏；弱实时系统（Soft Real-Time）：某些应用虽然提出了时间需求，但实时任务偶尔违反这种需求对系统的运行以及环境不会造成严重影响，如视频点播（Video-On-Demand，VOD）系统、信息采集与检索系统就是典型的弱实时系统。