嵌入式调试器（精选7篇）
嵌入式调试器 篇1
1 概述
现在嵌入式智能系统的软件功能越来越复杂, 接的外围设备也越来越多, 结果便携嵌入式设备耗电惊人。人们对手持和便携式嵌入式智能系统提高续航能力的要求愈加强烈。同时, 手持和便携设备的特点是便于移动, 所以不可能自身配有大体积大容量的电池。这样嵌入式智能系统的使用和续航能力之间产生了矛盾。为了解决这个矛盾, 不影响设备的移动性能, 只能从系统的耗电角度考虑节省更多的电能。现在很多嵌入式软件系统都有电源管理功能, 对系统软件和硬件进行能耗管理, 可是面对多种外围设备和丰富的软件资源都在正常工作的情况下, 较难获得整个系统休眠时的最低电流——底电流, 本文介绍一种能够较快并准确获得系统底电流的方法。通过该方法获得的底电流, 能够做为系统休眠的底电流的标准, 对比出系统电源管理的不当之处。本文使用INTEL PXA270芯片组成的嵌入式系统为例。
2 嵌入式系统的耗电分析
2.1 PXA270嵌入式系统功耗计算公式
P=C*V2*F。是文献[3]提供的PXA270正常情况下, 消耗的功率计算公式。但是对于半导体器件工作时还存在漏电流做功, 这部分功耗也应该计算在内。系统功耗的计算公式应为:P=C*V2*F+PL。P是单位时间内硬件系统总的功耗。PL是单位时间内半导体原件工作时产生的漏电流的功耗, 这个功耗对于给定的半导体原件来说是无法改变的, 在选择器件时应注意该指标。C*V2*F, 可以看出正常的供电情况下即V一定, 系统的功耗和系统电流C、系统频率F成正比。所以, 通过改变电流C, 和系统的工作频率F, 就能够改变系统的整个功耗, 提高电池的使用效率。
2.2 底电流的调试策略
要找到系统电流的最低值, 首先, 要简化系统的硬件。制作最小系统, 在最小系统运行时得到真实的底电流。最小系统具备嵌入式系统正常运行所使用的电压、时钟和存储器这些基础的硬件资源。第二, 要简化系统软件。在功能丰富的系统软件正常运行的情况下, 让系统睡眠, 难免会有对设备和软件控制失误和不当的地方, 影响系统的底电流。为了排除软件复杂度造成的影响, 我们选择在Bootloder启动代码中调试底电流。并使用文献[6]的方法通过串口把Bootloader程序保存到FLASH中。由PXA270构成的最小系统硬件结构, 如图1所示。
2.3 Bootloader启动程序中的电流调试
2.3.1 Bootloader启动代码的修改
这里对完整的Bootloader功能做了截取, 重点是去掉加载内核和主程序加载, 主函数入口跳转代码。因为, 我们的目的是在Bootloader的环境下调试硬件, 不需要加载和启动系统代码。同时在Bootloader中加入了PXA270的睡眠唤醒代码。Bootloader中的代码均为汇编语言编写。修改后的Bootloader流程如图2所示:
2.3.2睡眠配置
PXA270芯片有多种电源状态, 本文关注的是其中的STANDBY待机, SLEEP睡眠, DEEP SLEEP深度睡眠三种模式。实现的方式是, 在芯片的特权模式下向PWRMODE电源模式寄存器中写入模式对应的值, PXA270立刻进入低功耗状态。有关睡眠的寄存器配置步骤为:
(1) 配置睡眠配置寄存器 (PSLR) 或待机配置寄存器 (PSTR) 。
(2) 保存通用输入输出接口 (GPIO) 电平值到通用输入输出状态寄存器 (PGSR) 。
(3) 配置芯片电源模式寄存器 (PWRMODE) 。
配置PGSR是为了唤醒后恢复GPIO在睡眠前的输出状态;配置PSLR睡眠状态寄存器或PSTR待机状态寄存器主要是为了低功耗状态下仍为SRAM供电。
2.3.3 唤醒配置
PXA270在STANDBY模式下醒来后执行写入PWRMODE值之后的第一条语句;SLEEP和DEEP SLEEP模式下醒来是睡眠退出复位, 是复位操作。所以, Bootloader启动程序中对复位的原因进行了判断和处理。PXA270芯片的唤醒源有:GPIO, KEYPAD中断, USB中断, RTC alarm中断事件, 根据文献[2]唤醒源设置步骤为:
(1) 配置唤醒源设置寄存器 (PWER) , 使能唤醒源。
(2) 配置按键唤醒寄存器 (PKWR) (可选) 。
(3) 配置唤醒源电平边沿检测寄存器 (PRER和PFER) , 指定唤醒源的边沿检测类型。
2.3.4 UART串口配置
UART串口用于调试信息的打印, 使用了WINCE中的Dbgserial.c的代码。这部分代码只在调试时使用, 睡眠和退出睡眠功能调试成功后要去掉, 以免影响系统功耗。
3 实验结果
3.1 PXA270最小系统不同工作模式实测电流
使用数字电源供电, 对PXA270最小系统四种工作模式进行电流测试, 实验数据如表1所示:
3.2 唤醒测试
唤醒测试, 使用周期时钟事件 (Periodic RTC alarm) 作为唤醒源对PXA270最小系统进行定时睡眠和唤醒操作。睡眠和唤醒的时间比为4:1。连续睡眠唤醒电流图, 如图3所示:
3.3 结果分析
整个最小系统在SLEEP状态下内部的工作单元是PXA270的时钟、电源管理和处于自刷新状态的片外SDRAM。当PXA270带有外围设备, 由系统软件控制进入SLEEP时, 在正确关闭外围设备并且无板间漏电的情况下, 整个系统工作的也是PXA270的时钟、电源管理和处于自刷新状态的片外SDRAM。这和最小系统的SLEEP状态下的工作单元是完全相同的。所以, 最小系统的SLEEP电流值和复杂系统SLEEP状态下电流值是一样的。我们实际上调试的就是复杂系统正确进入SLEEP这种低功耗状态下所能达到的电流值。
4 结论
在嵌入式系统软件内核程序和应用程序运行后, 对系统的底电流进行调试是很难获得准确值的。本文从最简单的硬件系统和功能最少的软件着手, 对系统的低功耗状态进行调试获得系统实际能够到达的最小电流值, 并以此作为复杂系统的最小电流值的标准。
摘要：本文针对如何获得嵌入式系统低功耗状态下的准确电流值的方法进行了阐述和验证。硬件使用Intel PXA270芯片构成的最小系统为基础, 提出了软件先在bootloader中进行系统进入低功耗状态和退出低功耗状态的调试方法。调试过程中借助PXA270的UART进行调试信息的打印, 并从硬件输出的特征信号两个方面判断最小系统的功耗状态。分析了PXA270最小系统睡眠时功耗值与配有其它外围设备的PXA270嵌入式系统睡眠时功耗值应是同一个值的原因。
关键词：嵌入式系统,低功耗,软件,硬件,启动程序,调试方法
参考文献
[1]Stanislav Pavlov;Pavel Belvesky.Windows Embedded CE 6.0 Fun-damentals.[M].Washington, Microsoft Press, 2008.
[2]Intel PXA27x Processor Family Developer’s Manual[M].April 2004, Order Number:280000-001.
[3]Intel PXA27x Processor Family Power Requirements ApplicationNote[M].Order Number:280000-001.
[4]256-Mbit 1.8 Volt Intel StrataFlash?Wireless Memory (L18/L30) Stacked-Chip Scale Package (x16) Datasheet[M].252633.
[5]ARM Architecture Version 5T Specification (Document number ARMDDI 0100D-10) and ARM Architecture Reference Manual (ARMDDI 0100 or ISBN 0-201-73719-1) [M].
[6]郑建文, 李晓潮, 郭东辉.基于PXA270嵌入式系统的WindowsCE引导程序设计[J].中国集成电路, 2008, 4:67-73.
[7]邹健强, 陈耀武, 汪乐宇.基于Xscale处理器的Windows CE5.0BootLoader设计[J].现代机械, 2006, 4:55-57.
[8]李汉强, 丘巍.基于Intel PXA26X处理器的BootLoader的设计与实现[J].武汉理工大学学报, 2003, 27 (6) :770-773.
嵌入式调试器 篇2
近些年来，随着嵌入式集成电路技术的快速发展和人们对嵌入式产品需求的提高，嵌入式双核、四核移动处理器已经逐渐成为主流。然而正如传统桌面处理器一样，嵌入式软件的发展总是滞后于硬件的快速发展，软件开发的复杂性越来越大，开发成本和开发周期越来越长，在这种情势下，调试在嵌入式软件开发中的地位越来越重要。由于硬件资源有限，嵌入式软件开发中的调试主要为远程调试[2]。嵌入式软件开发中的远程调试主要有硬件调试和软件调试两大类，硬件调试虽然实时性强，但价格昂贵，通用性差，操作复杂;软件调试由于其成本低，通用性强，可移植性高而得到广泛的应用。
当前流行的远程调试代理工具主要是gdb Server。gdb Serve不仅性能稳定，而且支持大部分调试功能，但由于gdbserver是基于嵌入Linux操作系统开发的调试代理工具，不能应用于其他嵌入式操作系统。与桌面操作系统的单一化不同，由于应用环境的多样化，嵌入式操作系统也呈现多样化的趋势，单是常见的嵌入式操作系统就有十几种之多，如Vx Works、QNX、u C/OS-II等，但对于这些嵌入操作系统并没有现成的远程调试系统可用。
本文从嵌入式操作系统内核和调试代理两个方面详细分析了嵌入式调试器的的设计思路和实现流程，并合理地划分了操作系统和调试代理应提供的功能。以此为基础，在嵌入式实时操作系统a Coral上实现了一款嵌入式多线程软件调试器。
1 嵌入式远程调试体系结构的研究
嵌入式远程调试由目标机和宿主机两部分组成，其中调试代理运行在目标机端，完成具体的调试过程，宿主机调试器负责与调试代理通信，如图1所示。
调试人员在宿主机上运行宿主机调试器，在目标机上运行调试代理，宿主机调试器读入用户输入的命令后，将调试命令分解成一系列的数据报，并通过某种通信协议将这些数报发送给调试代理，调试代理根据收到的数据报完成具体的调试功能，然后将得到的结果再回送给调试代理，最后调试代理将收到的数据输出到宿主机终端动。
一个完整的嵌入式远程调试系统主要包括嵌入式操作系统内核和调试代理两个部分，总体来说操作系统内部要实现与调试相关的数据结构，并对外提供可应用于调试的系统调用供上层调试代理使用，调试代理利用操作系统提供的系统调用来实现远程调试功能。然而在一个调试系统哪些功能应试由操作系统内核来实现，哪些功能应该由调试代理来实现并不是一个容易解决的问题，如果把过多的功能放在内核中，虽然可以简化调试代理的开发，但另一方面却加重了内核的负担。本文通过仔细的研究后，合理地划分了操作系统和调试代理各自应该实现的功能，并给出了具体的实现细节，具体细节如图2所示。
由于每种调试功能实现起来都是非常复杂的，而且每种调试功能表面看起来有很大的不同，但其内部实现过程有许多部分是相同的。因此如果由内核来实现具体的调试功能，不仅增加了内核的负担，降低了内核的效率，使内核代码变得更加冗余，不易维护，而且可扩展性不强，如果以后增加其他的调试功能，只能修改内核，不能在应用层完成。本文通过分析常见调试命令的实现原理后，发现操作系统内核只要实现五个基本的功能，调试代理就可以使用操作系统提供的这五个基本的功能实现各种调试命令，这五个功能分别是:线程绑定，事件通知，控制线程运行状态，读写寄存器，读写进程地址空间，每种功能的具体描述和实现细节将在后面进行详细描述。在这种调试架构中，调试代理利用操作系统内核提供的功能实现调试命令，如图2所示，调试代理主要有通信处理，命令解析和事件驱动这三个核心部分组成，其中事件驱动是调试代理的核心，通信模块接收从宿主机发送的数据，命令解析模块从收到的数据中解析出调试命令，事件驱动机制来完成具体的调试过程。下面以断点为例来分析调试代理与目标机内核的交互过程，如图3所示。
命令接收模块接收到宿主机调试器发送的数据后，将收到的数据发送给命令解析模块，命令解析模块从收到的数据中解析出断点指令，然后就生成一个事件交由事件驱动模块处理。
设置断点就是用软中断指令替换当前指令，因此本质上还是一个读写进程地址空间的过程，通过内核提供的接口，首先将当前地址处的指令保存在一个缓冲区中，然后用将软中断指令写入当前地址处。当处理器遇到软中断指令后，会自动陷入内核，内核通过事件通知机制唤醒调试代理，同时将事件信息返回给调试代理。然后调试代理就根据内核返回的信息做进一步的处理。
可见只需利用操作系统内核提供的读写地址空间和事件通知机制这两种机制就可以基本上实现断点功能。
基于上述调试架构能够在任何一种嵌入式操作系统上快速实现一款功能完善，效率高，稳定性强，可扩展性好的远程调试系统。下面部分将具体分析架构中每个部分的实现原理和实现过程。
2 嵌入式操作系统内核
嵌入式操作系统内核中的调试部分主要包括核心数据结构和对线程的基本操作两个部分[4]，其中核心数据结构是整个调试架构的基础，它将调试对象有机地组合在一起，上层调试软件利用操作系统提供的这些基本操作来实现完整的调试功能。
2.1 数据结构
每个进程线程都有记录其信息的数据结构，称为进程控制块(PCB)和线程控制块(TCB)，为了记录调试进程和被调对象之间的调试关系和进程及线程本身的调试信息，需要在PCB和TCB中添加相关信息，如表1所示。
其中ptrace＿list为调试进程使用，用于记录当前被调对象，每当创建一个新的线程时，就将此线程的TCB链接到调试进程的ptrace＿list链表中。ptrace＿children为被调线程使用，用于指向ptrace＿list链表的下一项。在调试系统中，被调线程有两种父进程:parent和real＿parent，其中real＿parent为被调线程的真实父进程，即被调线程是由real＿parent所产生的，parent表示被调线程的当前父进程，在非调试状态下real＿parent与parent相等，但一旦进入调试状态，调试进程就成为被调进程的当前父进程，此时parent就代表调试进程。
2.2 嵌入式操作系统内核接口
嵌入式操作系统是整个调试系统的基础，它为调试代理提供基本的接口，调试代理利用操作系统提供的接口来实现更加复杂的调试功能。经过分析和研究之后，为了实现完整的调试功能，以下几个口是嵌入式操作系统必须提供的。
(1)绑定线程
绑定线程的意思为在被调线程和调试进程之间建立调试关系，本质上就是修改上面所述的数据结构。绑定分为两种，一种是静态绑定，一种是动态绑定。在静态绑定中，调试进程先启动，然后由调试进程启动被调线程，此时调试进程是被调线程的real＿parent，但在动态绑定中，被调线程可能先于调试进程启动，在建立调试关系之前，它们之间没有父子关系。
为了绑定一个线程，建立调试关系，首先将被调线程添加到调试进程的调试链表中(ptrace＿list)，并将被调线程的parent修改为调试进程，然后将被调线程标记为被调(ptrace)，如果是动态绑定的话，还要暂停被调线程，最后要根据调试进程是否是被调线程的真实父进程来判断是否暂停被调线程的父进程，如果调试进程不是被调线程的父进程，就要暂停父进程，由调试人员来作出进一步的调试动作。
(2)读写进程地址空间
通常情况下，进程地址空间的代码段是只读的，因此用户无权修改进程的代码段，但是在一些不支持硬件断点的处理器中，要实现断点功能，必须要向进程的代码段中插入软中断指令，因此就需要操作系统内核实现这个功能。例如调试代理要在某条指令后插入一条软中断指令，调试代理就将插入位置，指令长度，指令内容传入内核，由内核来完成具体的插入。为了防止用户恶意读写非法地址，内核在读写数据之前，首先要进行地址检查，确保要读写的地址位于用户空间。
(3)启动线程
在具体的调试过程中，被调线程可能由于许多原因暂停执行，如遇到断点，被调线程创建了一个新线程，收到了一个信号等，之后调试人员可能想要恢复暂停的线程，但由于调试代理运行在用户空间，因此调试代理没有调度线程的权限，也就无法重新启动暂停的线程。
启动线程的过程比较简单，主要分为两个步骤，设置线程的状态和重调度，如果线程已经处于运行状态，就直接返回，如果线程处于阻塞状态，就将线程设置为就绪状态，将其TCB加入到调度队列中，并唤醒此线程，使其参与下一次调度过程。
(4)读写寄存器
查看当前寄存器的值是常见的调试手段，每一个线程在内核中都有一个内核栈[5]，当线程从用户空间进入内核空间时，就将此时的寄存器值，返回地址等现场保存在线程的内核栈中，当之后进程从内核空间返回到用户空间时，就将恢复之前保存在内核栈中的信息，从而确保线程的正确执行，因此读写进程寄存器可以由读写线程的内核栈间接实现。每种架构的嵌入式处理器都有大量的寄存器，因此内核必须按一定的顺序将寄存器值压入内核栈中，只有这样才能在寄存器和内核栈之间建立起映射关系。
(5)事件通知
当被调线程正在运行时，调试代理处于阻塞状态，等待被调线程产生某个事件，例如被调线程创建了一个新线程，被调线程遇到了一个断点等，当某个事件发生后，内核必须通知调试代理并将具体的事件信息返回给调试代理，调试代理根据内核返回的事件信息判断出事件类型，根据不同的事件类型做出不同的动作。除此之外一旦发生了某种事件，内核必须暂停被调线程，以使用户有时间做出反应，各种嵌入式操作系统都会提供某种事件通知机制，例如Linux中的信号、u C/OS-II中的邮箱等。
3 调试代理
调试代理是一个工作于操作系统之上的调试软件，它一方面接收用户的调试命令，另一方面以操作系统提供的接口为基础完成具体的调试功能。下面详细描述其核心数据结构与运行机制。
3.1 线程信息
每一个被调线程都需要一个描述其信息的数据结构，所有这些数据结构通过指针链接在一起，形成一个线程链表。其中每个数据结构记录一个线程在调试过程中的各种数据信息，所记录的信息主要包括断点信息、单步信息、寄存器信息和此线程的当前状态等数据信息。
断点信息记录在此线程中所插入的断点，每个断点都有一个与断点相关的数据结构，所有的断点对应的数据结构构成一个链表。每个数据结构记录断点的各种属性，断点主要的属性包括断点的插入状态、断点的插入地址、断点插入之前此地址处的内容等。每当用户要在一个线程中插入一个断点时，就为此线程生成这样的一个结构，并链入线程的断点链表中。
在不支持硬件单步的处理器中，单步功能本质上也是由断点实现的，当用户输入单步命令后，就在下一条语句位置处插入一个断点，然后运行线程，当线程执行完当前语句后，在执行下一条语句时，就会遇到此断点，由此来模拟实现单步功能。
寄存器信息用于缓存被调线程的寄存器值，当用户查看某一个寄存器的值的时候，通常情况下用户马上还会查看同一寄存器或其他寄存器的值。因此为了提高效率，调试代理通常把所有的寄存器的值都缓存起来，这样当下次再次查看寄存器时，如果缓存有效就直接从缓存中读取。
线程的状态信息主要记录线程当前的运行状态以及和特定于操作系统的一些信息。线程的运行状态主要有暂停、运行和中止。同一状态可能由多种情况导致，而不同情况的后续处理方式却不同，比如在单步和遇到断点时，线程都会处于暂停状态，但后续的处理却有很大不同，因此除了记录以上三种状态外，还必须记录产生这种状态的原因。
3.2 事件驱动机制
事件驱动机制是整个调试代理的设计架构，整个调试代理就是基于事件驱动机制工作的。利用事件驱动机制，不仅提高了程序的并发能力，而且增加了程序每个模块之间的独立性，具有很高的扩展性。在此架构中，每当用户输入一个调试命令，就会产生一个或多个事件，然后由事件处理逻辑来处理每一个事件，当所有的事件都处理完后，调试代理就阻塞等待下一个事件的到来。
每个事件都有一个数据结构struct event，所有的事件形成一个事件链表，每个event结构由三个元素组成，最重要是fd和proc,fd表示事件源，即是谁产生了这个事件，proc为此事件的处理程序。正常情况下事件链表为空，调试代理阻塞在所有的事件源上，当某个或多个事件源有事件到来时，调试代理就被激活。接着调试代理就分配并初始化相应的事件，把事件注册到事件管理单元中，然后调用事件处理单元，事件处理单元就扫描每一个事件，并调用每个事件中的事件处理程序来处理事件。当所有的事件都已经处理完闭后，调试代理就再次阻塞在事件源上，等待下一个事件的到来。
4 远程调试系统在aCoral上的实现
a Coral是电子科技大学开发的开源嵌入式多核实时操作系统，a Coral支持多线程，支持多核处理器并且具用内存保护机制，代码精简，扩展性强[8]。本文将在嵌入式a Coral上实现一款调试代理。下面简要描述一下实现过程。
4.1 a Coral对多线程的支持
在线程方面，a Coral本身对线程有很好的支持，a Coral提供了完整的线程控制函数，如创建线程、暂停线程、恢复线程、中止线程等;为了防止线程之间的竞争，a Coral也提供了多种线程互斥机制，如互斥锁、信息量等。利用这些函数，可以很好地实现上面所说的大部分功能。
4.2 a Coral在事件通知方面的缺陷和改进
实现的关键点在于a Coral没有提供事件通知机制。当调试代理阻塞等待一个事件到来的时候，此时如果调试人员输入了一条调试命令，正常情况下操作系统应该唤醒调试代理，并返回给调试代理相关事件信息，但a Coral没有实现这一功能的函数。
这在调试单线程的时候没有问题，因为此时只有一个线程，当有事件到来时，操作系统只要将调试代理唤醒即可，调试代理知道肯定是此线程的事件。但当操作多线程的时候就会出现问题，因为在多线程调试中，在同一时刻可能会产生多个事件，如果仅仅将调试代理唤醒，调试代理将无法正确获知事件信息，也就无法正确完成调试过程。
在具体的实现过程中，在嵌入式a Coral内核中添加一个链表来实现事件通知机制，每当一个事件到来时，内核就将此事件信息作为链表元素插入内核维护的事件链表中，当同一时刻有多个事件到来，或者当调试代理正在处理其它的事件时，又有事件到来时，内核就将每一个到来的事件都封装成一个链表元素插入到链表中，当调试代理处理完当前事件，又陷入阻塞状态时，内核就扫描此链表，若链表不为空，内核就直接唤醒调试代理，并将链表头的事件返回给调试代理，如果链表为空，调试代理就继续阻塞直到下一个事件的到来。
4.3 功能验证
基于以上的设计思路，本文在嵌入式a Coral上实现了一款嵌入式远程调试工具，下面给出具体的测试环境和测试过程，其中开发板为mini2440(处理器型号为arm920t)，宿主机运行Ubuntu11.10操作系统，目标机运行a Coral，宿主机通过gdb与目标机上的调试代理建立调试连接。被调程序包含两个线程:thread1和thread2，每一个线程都运行快速排序代码，首先建立远程调试连接:
经过上面的测试可以看到本文的设计思路是正确的，能够完整的实现多线程调试。
5 结语
本文提出了嵌入式远程调试的基本设计思想和一种嵌入式远程调试架构。以此为基础，从嵌入式操作系统内核和调试代理两个方面详细分析了嵌入式远程调试工具的实现过程，分析了嵌入式操作系统内核对远程调试应该提供的接口并详细研究了这些接口的实现原理。之后又重点探讨了调试代理的设计原理，并对调试代理的事件驱动机制作了重点分析。最后着重分析了嵌入式a Coral中事件通知机制的缺陷和改进，并在a Cora上实现了一款嵌入式多线程远程调试工具。本文给嵌入式调试系统开发人员提供了帮助，使其开发出效率高、性能稳定、可扩展性强的调试系统。
参考文献
[1]龚兰兰.基于u C/OS II的远程调试模块的设计[J].计算机应用与软件,2010,27(7):97-99.
[2]姚放吾,丁皞.嵌入式远程调试器保护模式下调试功能的实现[J].计算机技术与发展,2011,21(4):242-245.
[3]李善平,刘文峰,王焕龙,等.Linux与嵌入式系统[M].北京:清华大学出版社,2006.
[4]张银奎.软件调试[M].北京:电子工业出版社,2008.
[5]毛德操,胡希明.Linux内核源代码情景分析[M].浙江大学出版社,2001.
[6]章辉,桥井,高桥,等.基于仿真器的源码级调试器设计与实现[J].计算机工程与设计,2010,31(8):1685-1688.
[7]黄光红,李钢,张仁斌.通用嵌入式系统远程调试器的研究与设计[J].计算机测量与控制,2008,16(6):853-854.
[8]多核嵌入式实时操作系统项目组.a Coral技术文档V1.0[EB/OL].(2010-09-03)[2012-12-10].http://www.acoral.org/admin/upload/111.rar.
[9]Bennett J.Howto:GDB remote serial Protocol:writing a RSP Server[EB/OL].http://www.embe-cosm.com/download/ean4.html.2011.
[10]Wenyu Chen,Dongpu Han,Dongcheng Tang,et al.A model of remote Debugger supporting multiple types of Connection[C]//2011 International Conference on Electronics,Communications and Control,9-11Sept 2011.Piscataway,NJ,USA:IEEE,2011.
[11]Akgul T,Kuacharoen P,Mooney V,et al.A debugger RTOS for embedded Systems[C].27th Euromicro Conference 2001.
嵌入式调试器 篇3
随着嵌入式系统技术的发展近年来ARM9作为一种嵌入式系统处理器,以其高性能、低功耗、低价格等优点得到了广泛的应用。同时Linux嵌入式操作系统,是一个免费的、具有良好可伸缩性与扩充性的操作系统,支持完整的硬件驱动程序、网络通信协议与多处理器的架构,其源码的公开更有利于操作系统嵌入式应用的开发和部署[1],使得两个系统能完美的结合。
本系统采用三星S3C2410A作为检测装置的处理器,内部的AD直接用于数据的采集。系统实现了使用传感器对用电设备进行检测,将模拟开关4051作为多种电能指标数据通道的选择,接入AD进行采集,最后利用以太网进行数据的在线传送。该系统以低成本实现了高端电力检测设备的主要功能,满足了电力能耗参数检测的实际需求。
1 系统总体设计
本系统由硬件和软件两部分组成,均采用模块化、标准化设计并充分考虑系统的扩展能力。
其中硬件部分包括传感器模块、通道选择模块、AD模块、ARM核心模块、以太网模块(见图1)。
软件部分包括通道选择模块、AD模块、以太网传输模块。
系统工作原理:先由CPU选择要采集数据的通道,由传感器把测量数据通过模拟开关4051传送到精度为10bitAD模块,并由其进行模拟信号到数字信号的转换,转换完成后,送到CPU处理,然后进入系统缓存存储,最后通过以太网传输到服务器进行分析及处理。
1.1 硬件系统分析、设计
1.1.1 硬件系统概述
硬件主系统:采用基于ARM 920T内核的SAMSUNG S3C2410处理器,主频202 MHz,配置64MB RAM,8寸640×480LCD。它不仅可以满足目前功能的需要,而且丰富的硬件资源可以实现网络检测以及未来功能扩展需要。
传感器:采用0.2级精度钳形电流传感器,根据系统硬件的需求在传感器输出端加入电压放大器,直接输出电压信号方便数据的采集。
1.1.2 硬件电路
(1)通道选择模块电路设计
使用S3C2410内部的AD。4051是模拟开关,有8个通道可以选择输入,传感器采集的数据由CPU通过P2输出信号选择有任一通道,由X端口输出数据,由于内部AD转换的模拟信号范围是0～3.3 V,所以串入1.7 K和3.3 K电阻,把3.3 K电阻的电压引入AD模块内进行转换。
(2)以太网传输数据模块设计
以太网模块:芯片采用DM9000AE。DM9000AE是16Bit 总线宽度,接在S3C2410的Bank2上,使用中断EINT2。DM9000AE的第32脚CMD用来指示当前数据总线是Index端口还是Data端口,开发板则将1根地址线A1接到第32脚,以此区分读写的是命令/地址还是数据(这点不同于其他具有多位地址线的芯片)。所以DM9000AE的Index端口的地址是0x10000000,Data端口的地址是0x10000002,驱动程序中只以这两个物理地址访问DM9000AE。
1.2 系统模块设计
(1)通道选择模块设计
负责进行通道选择。根据4051的资料,AB端口输入的信号不同,所选择的通道不同。本模块由CPU控制IO(VD2、VD0)端口输出高低电平,通过插针P2直接输入到4051的AB端口,选择不同通道来检测电能参数,数据直接由X端口传送出去。(对应关系见表1)
(2)数据采集模块
主要负责把传送的模拟信号转换为数字信号并进行储存。10bitAD把0～3.3 V的模拟信号等分为1 024份,然后进行数据采样把模拟信号转换成对应的数字信号后,由CPU控制进入系统缓存存储。
(3)数据传输模块设计
主要负责把存储的数据通过以太网传送服务器。
命令传送:本系统通过使用socket与服务器建立TCP/IP连接,来实现命令的传送[6]。
数据传输:数据采集存储后,可以直接采用命令传送的方式,把数据传输到客户机进行实时数据分析情况。如果数据不需进行实时分析,也可以存入SD卡中。
2 系统调试
由X端口输出的模拟信号经过串联电阻进入AD模块的模拟信号存在一个线性关系。接入的是1.7 K和3.3 K的电阻,如设由X端口输出的模拟信号为y,进入AD模拟信号的为x,理论上应该存在以下的线性关系:y=1.52x。但在实际调试过程中,3.3 K电阻引入的电压并未达到3.3 V,略调电阻使其达到3.3 V。原有线性关系被破坏,通过调整电阻值找到新的线性关系。
方法如下:用一台稳压电源把具有一定规律的
电压信号输入通道选择模块,并由X端口通过串联电阻输入到AD模块中,分别测出X端口输出电压值,以及AD端的电压值,并用最小二乘法将对应关系y=1.23x计算出来,并根据该结果重新设置软件参数(见图2)。
3 结论
本文介绍了基于ARM9的电力能耗检测设备的开发与调试,旨在通过该设备的开发,为构建能耗检测平台提供硬件支持。在开发过程中,笔者完成了如下的工作。
(1)传感器的改造、系统硬件配置及外围电路的设计制造;
(2)数据采集及数据传输软件的程序编制及调试;
(3)在硬件设计开发的基础上,开发了电能监测信息系统。该系统能够通过以太网向嵌入式设备发送通信请求,获取电能数据,并以曲线图表形式显示监测设备的状态。
通过实际应用测试发现,系统采集数据及时、准确、完整,系统运行稳定可靠。
运用该设备建立用电监测的数据平台,能够实时获取监控设备的能耗状态,掌握用电过程的数据资源,为能耗检测提供丰富的数据资料,为节能降耗提供有力的数据支持。
参考文献
[1]李伟华,武占河.基于ARM9的电能管理终端软硬件开发探讨[J].广东电力,2008,21(6):37-39.
[2]孙天泽,袁文菊.嵌入式设计及Ⅱnux驱动开发指南:基于ARM9处理器[M].北京:电子工业出版社,2006.
[3]Daniel P.Bovet,Marco Cesati.Understanding LinuxKernel[M].Published by O'Reilly Media.Inc,1005 GravensteinHighway North,Sebastopol,2005.
[4]周立功.ARM嵌入式系统基础教程[M].北京:北京航空航天大学出版社,2005.
[5]屈博,杨耿煌,张泽卉.基于ARM9Linux的手持电能质量分析仪[J].电子测量技术,2007,30(8):94-98.
[6]欧阳峥峥,林茂.基于TCP/IP协议通信软件的分析与实现[J].武汉工业学院学报,2005,24(2):12-14.
[7]汤秋芳,罗梅林,周少武,等.基于ARM多用户智能电能表设计[J].现代电子技术,2009(6):158-161.
[8]殷文强,李春生,邹卫明,等.建筑能耗分析思路及节能诊断方法[J].节能技术,2011,29(5):446-449.
嵌入式调试器 篇4
嵌入式系统是后PC时代的主导, 当低端的嵌入式系统无法满足信息化、智能化、网络化时代的更高要求时, 32位嵌入式系统应运而生。32位嵌入式系统是电脑硬件与软件的有机结合。嵌入式设计的目的在于满足某种特殊的功能。嵌入式系统的大体构架可分为五部分:处理器、内存、输入与输出、操作系统与应用软件。32位嵌入式系统可分为硬件和软件两个平台。硬件平台的设计包括处理器电路、网络功能、无线通信及使用接口等的设计。嵌入式软件为信息、通信网络或消费性电子产品等系统中的必备软件, 为硬件产品的驱动程序, 控制处理和基本接口功能服务, 以提高硬件产品的价值。嵌入式软件为该硬件产品不可缺少的重要组成部分。
2 32位嵌入式系统的应用现状
嵌入式系统把微处理器 (CPU) 或者微控制器 (MCU) 的系统电路与其专用的软件平台相结合, 以此来达到系统操作的最高效率。目前的移动电话、手表、电子游戏机、PDA、电视、冰箱等民用电子与通信设备, 电动汽车、电动机车等电动产品的控制核心, 无不与32位嵌入式系统息息相关。32位嵌入式系统早已融入了人们的日常生活, 嵌入式系统的产品主要集中在信息家电、通信产品、工业控制器、掌上电脑 (PDA) 领域。家电、玩具、汽车、新一代手机、数码相机等设备也都采用了32位嵌入式系统的核心技术。随着后PC时代的到来, 有理由相信32位嵌入式系统会呈现出蓬勃发展的趋势。
3 边界扫描技术 (JTAG)
边界扫描技术是为了满足当今深度嵌入式系统调试的需要而被IEEE1149.1标准所采纳, 全称是标准测试访问接口与边界扫描结构 (Standard Test Access Portand Boundary Scan Architecture) 。JTAG遵循1149.1标准, 是面向用户的测试接口, 是ARM处理器调试的基础。本文提到的ARM的E-TRACE调试模式实际上是JTAG的增强版本, 其它一些32位嵌入式处理器的调试方式也基本上遵循这个标准。这个用户接口一般由4个引脚组成:测试数据输入 (TDI) 、测试数据输出 (TDO) 、测试时钟 (TCK) 、测试模式选择引脚 (TMS) , 有的还加了一个异步测试复位引脚 (TRST) 。
所谓边界扫描就是将芯片内部内科所有的引脚通过边界扫描单元 (BSC) 串接起来, 从JTAG的TDI引入, TDO引出。芯片内的边界扫描链由许多的BSC组成, 通过这些扫描单元, 可以实现许多在线仿真器的功能。根据1149.1的规定, 芯片内的片上调试逻辑通常包括一个测试访问接口控制器 (TAP) 。它是一个16状态的有限状态机以及测试指令寄存器、数据寄存器、旁路寄存器和芯片标识寄存器等。在正常模式下, 这些测试单元 (BSC) 是不可见的。一旦进入调试状态, 调试指令和数据从TDI进入, 沿着测试链通过测试单元送到芯片的各个引脚和测试寄存器中, 通过不同的测试指令来完成不同的测试功能。包括用于测试外部电气连接和外围芯片功能的外部模式以及用于芯片内部功能测试 (对芯片生产商) 的内部模式, 还可以访问和修改CPU寄存器和存储器, 设置软件断点, 单步执行, 下载程序等。其优点如下:
1) 可以通过边界扫描操作测试整个板的电气连接, 特点是为表面贴元件提供方便;
2) 各个引脚信号的采样, 并可强制引脚输出用以测试外围芯片;
3) 可以软件下载、执行、调试和控制, 为复杂的实时跟踪调试提供路径;
4) 可以进行多内核和多处理器的板级和芯片级的调试, 通过串接, 为芯片制造商提供芯片生产、测试的途径。
虽然JTAG调试不占用系统资源, 能够调试没有外部总线的芯片, 代价也非常小;但是由于JTAG是通过串口依次传递数据, 速度比较慢, 只能进行软件断点级别的调试, 自身还不能完成实时跟踪和多种事件触发等复杂调试功能。因此便有了几种功能更为完善的增强版本。
4 ARM芯片的实时调试方案 (E-TRACE)
ARM公司的内核芯片采用E-TRACE片上调试模式。它实际上是JTAG的升级版本, 通过增强的辅助片上调试硬件来完成实时调试, 解决了许多传统调试器难以解决的问题。
它的实时调试方案通过三种途径解决:
1) Embedded ICE硬逻辑;
2) 实时监控;
3) 实时跟踪。
Embedded ICE逻辑单元存在于ARM7TDMI、ARM9TDMI、ARM9E和ARM10内核中。它在JTAG的基础上, 增加了硬件断点寄存器、比较器, 通过断点寄存器的值可以进行硬件断点的设置, 不仅对地址还可以对数据、控制总线的信号进行复杂的触发控制设定, 而不是单单在指令级别进行中断 (如软中断) , 从而满足对特定事件的中断响应, 极大的增加了灵活性, 同时可以在ROM中设置断点和观察点, 极大地方便调试。
实时监控则是进一步在ARM9E和ARM10中的改进。它改变Embedded ICE在触发中断后进入调试模式状态而停止内核运行的弊端, 进入一段非常小的中断监控程序中, 得到所需要的信息后迅速把控制权转让给先前的任务 (这是与远程监控器最大的区别) 。在监控程序内处理器完全可以再接收外界的中断和其他触发事件, 而不是停止运行。这种方式综合了JTAG和远程调试的优点, 它可以增加以下两个好处:
(1) 在不禁止中断的前提下调试前景任务 (即中断时正在运行的任务) ;
(2) 不用停止处理器的运行就可以读写和修改存储器 (对于机电设备非常重要) 。
更为强大的是ARM的实时跟踪解决方案, 它由三个部分组成:
(1) 嵌入跟踪微核;
(2) 跟踪分析仪;
(3) 跟踪调试软件。
通过这三种工具可实现完全的实时跟踪。跟踪微核存在于芯片, 它可以不停止CPU的运行而实时监视芯片总线的信息, 并把设定触发范围内的所有信息在CPU运行的同时通过压缩的方式送到外部的跟踪分析仪器里。分析跟踪仪器从芯片外部通过跟踪口 (另外一个不同于JTAG的接口) 收取信息。因为是压缩的数据, 所以分析仪不需要采用与跟踪微核实时跟踪相同的速度。这大大降低了分析的成本, 并增加了存储的容量。而PC端的跟踪软件则将来自分析仪的数据重新组织起来, 从而重现处理器的历史状态和数据、程序流程。同时还可以把执行代码与源代码链接起来, 使调试者快速理解跟踪数据。ARM的这种方式通过芯片内部的实时跟踪硬件加上低成本的分析仪器, 解决了传统在线仿真器 (ICE) 和逻辑分析仪的诸多弊端。
5 Nexus标准
自从JTAG IEEE1149.1标准出来后, 越来越多的高端嵌入芯片生产商开始采用这个标准。但是1149.1标准只能提供一种静态的调试方法, 如处理器的启动和停止、软件断点、单步执行、修改寄存器, 而不能提供处理器实时运行时的信息。于是各个厂家在自己的芯片上, 把原有的JTAG的基本功能进行了加强和扩展, 如前面提到的E-TRACE、背景调试模式BDM (Background Debugging Mode) 和片上仿真On CE (On-Chip Emulation) 等, 在处理器不停止运行的前提下, 进行实时的调试。
由于这些增强的JTAG版本之间各有差异, 而且即使同一厂家的不同产品之间也存在着不同, 所以一些芯片厂商和调试工具开发公司于1998年成立了Nexus 5001论坛, 以期提出一个在JTAG之上的嵌入式处理器调度的统一标准。
Nexus将调试开发分成四级, 从第一级开始, 每级的复杂度都在增加, 并且上级功能覆盖下一级。第一级使用JTAG的简单静态调试;第二级支持编程跟踪和实时多任务的跟踪, 并使用户用I/O引脚作为多路复用辅助调试口;第三级包括处理器运行时的数据写入跟踪和存储器的读写跟踪;第四级增加了存储替换并触发复杂的硬件断点。从第二级开始, Nexus规定了可变的辅助口。辅助口使用3~16个数据引脚, 用来帮助其他仿真器和分析仪之类的辅助调试工具。
通过Nexus标准可以解以下问题:
(1) 调试内部总线没有引出的处理器, 如含有片内内存器的芯片;
(2) 传统在线仿真器无法实现的高速调试;
(3) 深度流水线和有片上Cache的芯片, 能够探测具体哪条指令被取和最终执行;
(4) 可以稳定地进行多内核处理器的调试。
6 调试技术的展望
通过上面的分析可以看出, 目前的调试技术可以在频率100MHz、内部总线外部不可见、需要进行实时跟踪的情况下发挥优势, 弥补传统的远程调试器和在线仿真器的不足, 并且成本非常低廉。
同时, 调试技术还在不停地发展, 目前IEEE1149.4标准也已经产生。它主要是将边界扫描结构用于处理模数混合芯片的调试。Nexus也已经完成了标准的制定并有厂商开始在芯片上提供Nexus的调试硬件模块。但是这些标准到底会不会被各个芯片厂商所采用, 还有待时机的成熟。特别是两大主流内核公司ARM和MIPS分别采用了自已独特的内核调试技术。
参考文献
[1]马忠梅, 等.ARM嵌入式处理器结构与应用基础.北京航空航天大学出版社, 2002.
嵌入式调试器 篇5
嵌入式系统调试一般使用串口、JTAG、USB或网卡来下载系统镜像到目标机中。使用串口下载镜像,协议简单,接口通用,但传输速率太慢。使用JTAG下载镜像,传输速率较高,但需要专用的JTAG调试器,价格较高,限制了调试环境。使用USB或网卡下载镜像速度快、接口通用,但一般做成产品后的嵌入式设备不需要留出通用的USB或以太网接口,从而增加了设计的复杂性和开发成本。在移动嵌入式产品开发过程中,如果使用Trans Flash(TF)卡[1,2]代替USB或以太网口,由于TF卡一般又都是移动嵌入式产品的必要构成部分,这样做一般可以减小嵌入式系统调试的复杂性和成本。本文提出使用TF卡更新镜像的方法,并在实际的嵌入式系统调试中成功应用。使用TF卡下载系统镜像,速度与通用性都很好,既省去了调试中对其他下载设备的设计需求,又解决了最终产品大容量存储器的设计问题。
1 Trans Flash卡与应用处理器的连接电路设计
本文调试的嵌入式系统,是一种视频数据采集与传输单元,以PXA310为中央处理器,采集到的视频数据由PXA310[3]进行压缩编码处理,之后发送到网络中去,供用户查看。系统调试过程中,视频数据可以存储到TF卡中。
TF卡模块在系统中主要有两个方面的作用:
一是在嵌入式系统开发调试过程中用于将系统镜像到目标版;
二是作为最终嵌入式系统产品的大容量存储器。
SD卡有两个可选的通信协议:SD模式和SPI模式。SD模式是SD卡标准的读写方式,但要求主控制器带有SD卡控制器。PXA310本身没有TF卡控制器接口,选用SD模式通信就无形中增加了产品的硬件成本,选择SPI模式可以说是一种最佳的解决方案,相对于SD模式,SPI模式接口与协议简单、易于操作。这时TF卡在PXA310 MMC/SD/SDIO主控制器控制下工作。
2 Blob中TF卡的驱动设计以及FAT32文件系统移植
2.1 设计TF卡SPI模式驱动
TF卡操作遵循SD卡协议,TF卡的操作完全与SD卡相同[1,2,4]。相对于SD模式,SPI模式接口与协议简单、易于操作。PXA310带有MMC/SD/SDIO主控制器,但由于Blob中没有提供SD卡与主控制器的具体驱动,实现完整驱动的难度较大,故本文采用GPIO口模拟的SPI模式读写TF卡,运行到Linux内核后再加载主控制器驱动运行SD模式的方式,性能与实现难度都可兼顾。
SPI模式TF卡总线采用主从问答式协议。主机发送命令Command,TF卡应答回复Response。SD卡命令有两种,CMDx和ACMDx。ACMD是应用指令集,属于扩展指令集,在发送任何的ACMD之前,必须先发送CMD55激活,才可以使用ACMD指令集。发送完一个ACMD,并且卡响应了此指令之后,CMD55的作用就消失了,所以要发送多个或多次发送一个ACMD,需要循环发送CMD55+ACMD。
2.2 SPI模式初始化TF卡流程
TF卡默认的通信模式是SD模式,本文要在SPI模式下设计TF卡驱动,需要从SD模式切换到SPI。为此,先将TF卡上电,延时74个时钟周期后发送复位命令CMD0,同时将SD卡的CS片选信号置低,若此时接收到应答信号为0x01,说明TF卡进入了SPI模式。
TF卡与MMC卡都可用SPI模式驱动,故在初始化时可考虑与MMC卡的兼容性。在发送CMD0成功接收到应答信号后,连续发送CMD55+ACMD41,若CMD55回复0x01而ACMD41回复0x00,则TF卡初始化成功。若没有完整的应答,则改发CMD1,若CMD1成功回复0x00,则MMC卡初始化成功。
在SPI模式下,TF卡的初始化时钟频率不能超过400 k Hz。初始化成功后,就可以配置高速时钟下TF卡的读写操作了。图2为TF卡初始化流程图。
在Blob中完成TF卡初始化,还需要初始化PXA310的GPIO口,并根据对应TF卡的引脚配置其输入输出关系。
在Blob中,PXA310的PXA_SD_D2、PXA_SD_D3、PXA_SD_CMD、PXA_SD_CLK、PXA_SD_D0、PXA_SD_D1这几个I/O口并没设置为GPIO口,不能在软件上进行读写操作,要使用SPI模式,必须将这几个IO口设置为GPIO。通过在MFP寄存器中配置IO口的功能号,再配置相应参数即可实现。
2.3 通过SPI读写TF卡的程序设计
TF卡的读写以块为单位,初始化完成后,使用CMD16设置SD卡读写块长度(512 B),发送CMD17和CMD24读单块写单块,发送CMD18和CMD25读多块和写多块。实现TF驱动层中读写函数的逻辑流程如图3所示。
2.4 FAT32文件系统移植
在文中,FAT32文件系统移植主要包括系统初始化和文件管理程序修改(主要是文件读取)。FAT32的初始化就是找到各个部分的起始扇区位置。首先查找MBR的分区表,获取分区信息,然后找到每个分区的DBR,再根据DBR中的BPB得到分区的起始扇区、结束扇区、文件系统类型、FAT表个数、每簇占用扇区数等信息。最后根据下面的算法得到文件分配表FAT、文件目录表FDT和数据区DATA的起始扇区。FAT32读取文件流程如图4所示。
2.5 设计Blob命令下载系统镜像
Blob启动之后,首先初始化一些基本的硬件设备如串口等,然后检测系统内存映射,设置CPU运行频率等一些参数,接着就进入了命令行模式。
在Blob中提供tfdownload命令,主函数的形参就是接收到的命令内容和参数。若参数为“init”,则调用TF卡驱动的初始化,否则将此参数作为文件名传给FAT32文件系统打开并读取文件内容。最终实现“tfdownload init”调用TF卡驱动初始化TF卡。使用“tfdownload”+文件名可以调用FAT32文件系统和TF卡的驱动下载该文件名的镜像到内存中。
2.6 Make File文件修改与交叉编译
(1)TF卡驱动与FAT32文件系统编译
按照Blob中驱动程序的结构,TF卡驱动与FAT32文件系统源文件保存在/src/blob/Platform/Common/Source目录下,而FAT32文件系统头文件在/src/blob/Platform/Common/include目录下,要在编译Blob的时候将添加的驱动一起编译,需要更改相应的Makefile。在/src/blob/Platform/Source下有三个Makefile文件,分别是Makefile.am,Makefile和Makefile.in,修改Makefile.am即可,Makefile和Makefile.in会自动修改。主要增加Makefile的头文件寻找目录和编译文件。
(2)Blob命令编译
src/commands下的命令编译由同目录的Makefile确定,同样需要修改Makefile使添加的命令编译到Blob中去。另外,要使该命令在Blob中生效,还需要修改Blob的configure.in文件,在configure.in中添加:
(3)编译Blob
linux-2.6.25中集成了Blob,用linux-2.6.25的工具链编译好之后,在.../pxalinux/MHN-LINUX-PLATFORM/rel/target/bin中,boot_nontrust.bin就是生成的Blob镜像。
2.7 系统镜像下载的实现
先用tfdownload init命令初始化TF卡驱动,然后使用tfdownload下载系统镜像到内存中,再使用Nandwrite命令写入Nand Flash中。
3 Android下挂载TF卡实现数据存储
在Android系统中使用TF卡做储存器,必须先将TF卡挂载到Android上。要启用vold,需要在Android启动配置文件init.rc中关闭mountd并开启vold服务。通过对配置文件init.rc进行下面的修改完成此项功能。
vold.conf文件是vold程序挂载设备的配置文件,里面记载了挂载设备的设备路径、设备类型以及挂载的目标位置(挂载点)。需要在该文件中加入TF卡的挂载信息,然后,将vold.conf加入到system/etc目录下,vold程序就可以直接读取该配置文件了。
FAT32属于Windows分区,因为Windows分区里面的文件是没有权限这个概念的,所以在Linux系统中使用此分区时要手动指定默认权限。挂载TF卡之后Android的/sdcard目录不能直接通过chmod命令来修改对于system组的读写权限,在system下是无法直接访问TF卡的,需要在挂载的时候添加权限。在vold中,真实挂载TF卡的操作如下:
其中uid代表属主,uid=1 000代表system用户,fmask和dmask分别对应文件和目录的权限8进制码的反码。
4 设计结果展示
本文调试的数据采集与传输单元实物如图5所示,TF卡位于PCB板右上角。使用该单元录制视频并保存在TF卡中,设定录制时间为30 s,30 s后关闭,取出TF卡,将TF卡与PC连接,录像文件效果如图6所示。
使用TF卡下载系统镜像操作步骤如下:
(1)用“tfdownload init”命令初始化TF卡驱动,返回“TF CARD INIT SUCCESS!”即表示TF卡初始化成功。
(2)然后使用“tfdownload”+文件名的方式下载系统镜像到内存中,显示“TFCARD download done!”即表示TF卡下载镜像成功。
(3)最后使用Nandwrite命令将内存中的镜像写入Nand Flash中,返回“Done!”即表示写入成功。
使用vold挂载TF卡的操作结果如图7所示。其中“logcat–s vold”用来显示vold运行的输出信息。“New MMC card‘0000’added”表示成功加载TF卡,“Disk…..New blkdev 179.0”表示TF卡作为一个块设备被成功加载,“Partition…..New blkdev 179.1”表示TF卡第一个分区被成功加载,“Successfully mounted vfat filesystem179:1”表示成功挂载FAT32分区。到这一步,Android系统就已经成功挂载了FAT32系统的TF卡。
5 结语
本文结合嵌入式开发调试和嵌入式大容量存储的背景,提出并实现了一个使用TF卡进行嵌入式系统开发调试及存储应用的方案。在嵌入式系统调试中使用TF卡下载系统镜像,速度与通用性都很好,还可以很方便的和PC机交换数据。作为嵌入式产品的一个构成部分,使用TF卡调试既省去了其他下载设备的设计,又可以在系统中作为大容量存储器使用。本文具体完成的工作包括TF卡同应用处理器的连接电路设计、TF卡的驱动程序设计和FAT32文件系统移植、在Android平台下实现了TF卡的自动挂载。
参考文献
[1]SD Group.SD specifications:part1 physical layer simplifiedspecifications[M/OL].[2010-05-18].https://www.sdcard.org/downloads/pls/simplified_specs/Part_1_Physical_Layer_Simpli fied_Specification_Ver_3.01_Final_100518.pdf.
[2]SD Group.SD specifications:partA1 advanced security SD extension[M/OL].[2010-05-18].https://www.sdcard.org/down loads/pls/simplified_specs/Part_A1_ASSD_Extension_Simpli fied_Specification_Ver2.00_Final_100518.pdf.
[3]Marvell Semiconductor.System and timer configuration developersmanual[EB/OL].[2009-04-06].http://www.docin.com/p 65568787.html.
[4]SD Group.SD secifications:partA2 SD host controller simpli fied specifications[M/OL].[2007-02-08].https://www.sdcard.org/developers/overview/host_controller/simple_spec/Simplified_SD_Host_Controller_Spec.pdf.
[5]Code Home.Android:an open handset alliance project[EB/OL].[2008-01-01].http://code.google.com/p/android/.
嵌入式调试器 篇6
在嵌入式软件开发的过程中, 由于目标机通常不具备自举开发的能力, 嵌入式软件开发大多采取远程调试 (交叉调试) 的方式, 即让调试器运行在宿主机上, 被调试程序运行在目标机上, 主机和目标机之间通过某种通信端口如串口、并口、以太网等进行连接。
ARC810是台湾信亿科技生产的32位处理器, 笔者所在的实验室为其开发了一套调试工具【1】, 并命名为ARCDSU, 该调试工具的宿主机为PC机, 通过串口发送调试命令给目标机, 待调试的程序也通过串口进行下载。经过测试, 发现下载速度只有3.79kB/s, 当调试比较大的程序, 如Linux内核, 下载速度慢影响了调试速度。针对这个不足, 本文根据ARC810具有PCI接口的特点, 设计了通过PCI以太网卡下载待调试程序的方案, 下载速度达到418kB/s, 取得了满意的结果。
1、ARC810调试基本原理
ARC810处理器是基于LEON2内核的一款SOC芯片, LEON2内核是欧洲航天局所属研究所开发的基于SPARC V8架构的开源的32位RISC处理器。ARC810的调试方法与LEON2相同, 通过芯片上的调试支持单元进行软件调试, 该单元由2个模块组成:调试支持单元 (DSU) 和调试通信链路 (DCL) 。DSU能够使处理器进入调试模式, 只有在调试模式下才能访问处理器的寄存器和高速缓存器;DSU还包含了一个跟踪缓存器, 这个缓存器存储了执行过的指令和在AHB总线上传输的数据。DCL使用一个标准的异步UART来实现与宿主机上运行的软件调试器通信, 通信协议是简单的读写协议[2]。该硬件调试单元的模块图如图1所示。
笔者所在的实验室以模块化的思想为ARC810开发了一套调试工具ARCDSU, 其宿主机和目标机之间采取的串口通讯方式极大的限制了待调试程序的下载速度, 因此本文设计了通过以太网卡下载待调试程序的方案并加以实现。
2、基于以太网调试的方案设计
2.1 硬件系统结构
ARC810的内部模块图[3]如图2所示:
该处理器采用SPARC V8结构的32位处理器, 具有分开的指令和数据缓冲, 硬件乘除法器, 中断控制器, 带有跟踪缓冲区的调试支持单元、2个24位Timer、2个UART、1个watchdog、16位的I/O口、内存控制器、PCI接口和SPI。
ARC810支持PCI2.2标准, 可以通过PCI口扩展外设。本论文的实验平台具有PCI插槽, 在插槽上插入D-Link公司所生产的DFE-530TX, REV-C2网卡, 通过该PCI网卡实现目标机和宿主机之间的通讯。
2.2:软件系统结构
2.2.1:目标机网卡监听程序
该网卡监听程序由于涉及到以太网数据的接受和发送, 因此和网卡的驱动程序在网卡初始化, 网卡数据缓冲区的设计上都有相似之处, 但是由于并不和操作系统打交道, 因此在数据包的接受和发送上面与驱动程序又有所不同。系统流程图如图3所示:
网卡的初始化主要完成网卡的挂载, 网卡相关寄存器的初始化, 网卡发送和接受缓冲区的分配等工作。只有网卡正常初始化之后, 数据的接受和发送才能正常的进行。在网卡的初始化过程中由于要对网卡寄存器进行读写, 因此首先要确保I/O函数的正确性, 尤其要注意大小端的问题, 在分配发送、接受缓冲区的时候要根据所用网卡的硬件要求来处理字节对齐的问题[4], 否则网卡不能正确的收发。由于不涉及到操作系统, 我们还需要读出网卡的MAC地址, 以供网卡在接收和发送数据时使用。
网卡采取轮询的方式来接收PC机发送的数据包, 并根据数据包的种类回应相应的包。由于没有网络协议栈, 收到的数据包是否是目标机所需要的, 以及数据包的类型都需要我们自己来判断。判断的依据是数据包的以太网包头。我们根据包头的type code来判断收到的数据包是ARP包还是IP包。如果是ARP包, 再进行IP地址匹配检测之后决定是否回应ARP包;如果是IP包, 还要判断此IP包是否是需要的UDP包。
在本监听程序的设计当中, 网卡不主动向外发送数据, 只有当网卡接受到数据包之后, 再根据数据包的类型来决定是否回应此数据包。在回应ARP包的时候, 按照ARP包格式进行组包, 在回应UDP包的时候, 按照UDP包格式进行组包。其中要注意的是, 由于没有网络协议栈, 因此以太网头和IP包头都需要自行添加。在进行UDP的组包的时候, IP头中的header checksum域要自行计算, 如果此域填写不正确, 那么将不能正常的和宿主机进行通信。
2.2.2:宿主机数据发送程序
宿主机端的程序首先将待下载程序文件等长度分包, 然后根据通信协议与目标机进行交互。宿主机端要维护一个全局的序列号, 在发送数据包的时候, 当前序列号的值将按通信协议要求与数据打成一个UDP包发送出去。目标机端收到数据包之后, 将序列号提取出来和自身维护的序列号进行对比。如果两者相同, 则确认此包正确, 并回应宿主机, 宿主机可接着发下一包;如果两者不同, 则要求宿主机重发目标机所要求序列号的数据包。比如宿主机这时发送的是0号数据包, 如果收到包时目标机维护的全局序列号是0, 则表示此包正确, 目标机端将其维护的全局序列号加1;如果收到包时目标机维护的全局序列号不是0, 则表示此包不正确, 并组包要求宿主机发送自己序列号的数据包。
2.3:通信协议设计
为了实现宿主机和目标机在下载程序时候的通信, 我们借鉴了GAISLER公司的EDCL协议。EDCL是Ethernet Debug Communication Link的简称, 是该公司为grlib IP core所开发, 用以通过以太网来访问片上AHB总线。通过该协议能够对AHB总线上的任意地址空间进行读写操作。
EDCL协议要求的以太网包的格式[5]如图4所示:
其中4字节的Address是用来表示所要操作的内存空间, 4字节的Control world说明了宿主机和目标机在传输数据时所遵循的控制方法, 这4个字节的内容在目标机接受和发送数据时有所不同。
目标机接收数据时, Control word的内容[4]如图5所示:
其中16位的OFFSET是用来使应用层其余数据在内存中保持字对齐, R/W读写为表明了要执行的是读操作还是写操作。10位的长度位说明了要操作的数据的长度。如果R/W位为1, 则图4中的数据域就是要写的数据, 如果R/W位为0, 则数据域中的内容为空。
当目标机回应宿主机时, Contorl word的内容[4]如图6所示:
当目标机接收数据的时候, 14位的序列号将和内部维护的一个计数器进行匹配, 如果两者不匹配, 则不进行任何操作, ACK/NAK位置1, 回复包的序列号域为内部计数器的值;如果两者相匹配, 则进行相应的操作, ACK/NAK位置0, 内部计数器的值加1, 回复包的序列号域的为内部计数器更新后的值。当ACK/NAK位置1时, 长度域的内容为0。
由于我们不涉及到读操作, 我们可以将注意力集中在R/W为1的情况。并且因为我们是在软件上模拟内部计数器, 而当要传输的文件比较大时, 数据包的数量可能超过14位序列号所表能表示的范围, 因此在进行序列号和内部计数器的匹配操作的时候, 需要对内部计数器进行掩码操作, 掩码为0x00003fff。
2.4 源代码级调试流程
我们将做好的目标机网卡监听程序和目标板的初始化程序烧制在目标板的flash中, 这样目标板在启动的时候便会自动完成初始化并执行网卡监听程序, 这时候在宿主机执行数据发送程序下载待调试的程序。下载完毕之后, 就可以启动ARCDSU配合GDB进行源代码级的调试。
3、性能测试与优化
我们编写了一个helloworld程序来测试, 测试结果如图7所示:
测试结果表明, 在通过以太网下载了待调试的文件之后, 在gdb下不必执行download命令即可进行调试。
在测试过程中, 我们发现宿主机发包程序的组包长度下载速度有着较大的影响。在测试文件大小为5M的情况下, 包长512字节需时12秒, 包长256字节则需时21秒。
4、总结
本文通过实现以太网来下载待调试程序, 改进了通过串口下载程序较慢的缺点, 对缩短在arc810平台上开发嵌入式软件的周期具有重要意义。该软件不仅能下载待调试程序, 而且还能下载linux印象文件至开发板, 软件已通过测试, 在这里感谢厦门宜展科技提供的帮助。
参考文献
[1].吴志雄, 周剑扬, 卢敏.一种易于扩展的交叉调试器设计及其实现[J].电子技术, 2007/Z3
[2].LEON2 Processor User's Manual[Z].http://www.gaisler.com/, 2005
[3].ACARD 810 User's Manual[Z].2005
[4].VIA Rhine Family Fast Ethernet Controller Programming Guide[Z], 2007
嵌入式调试器 篇7
SignalTapII是基于逻辑分析核的嵌入式逻辑分析仪[1],是Altera公司QuartusII设计软件中的调试工具,伴随EDA工具的快速发展应运而生。它利用可编程逻辑器件的内部资源,将片外调试工具的逻辑移植到片内,直接在片内实现系统调试,不但具有普通逻辑分析仪的功能,包括触发、数据采集和存储等,而且还可以访问FPGA器件内部所有的信号和节点,解决了器件管脚不够或不方便外挂测试夹具而引起的测试问题,减少了电路板的空间,避开了电路板测试连接器引起的信号完整性和时钟问题,并能方便地测试出FPGA内部不同设计层的信号,满足FPGA系统开发中硬件调试的需要。
1 SignalTapII原理及操作流程
SignalTapII全称SignalTapII Logic Analyzer,是第二代系统级调试工具,它主要用于分析数字系统的检测和故障诊断问题,是数据域测试中一种非常有效的测试方法[2]。它可以捕获和显示实时信号,观察在系统设计中的硬件和软件之间的互相作用。软件可以选择要捕获的信号、开始捕获的时间,以及要捕获多少数据样本。还可以选择时间数据从器件的存储器块通过JTAG端口传送至SignalTapII,还是至I/O引脚以供外部逻辑分析仪或示波器使用,将实时数据提供给开发者以方便调试。
SignalTapII获取实时数据的原理如图1所示,它是将嵌入式逻辑分析仪内核插入FPGA设计中,满足触发条件时SignalTapII将启动采样并储存数据暂存于目标器件的片内RAM中,采样数据不断刷新片内存储器内容,通过JTAG端口采用ByteblasterII或者USB blaster下载电缆将捕获的信号数据从器件的RAM资源上载至QuartusII开发环境以实时显示波形。这样就可以使开发者在整个设计过程中观察硬件和软件的交互作用[3]。
若没有SignalTapII接口,用户必须更改设计以探测内部逻辑的连线。设计的内部连线必须连接到顶层设计的管脚上。如果节点处于庞大分级设计的下层,那么改起来很复杂,同时很耗时,而且破坏了设计的完整性。嵌入式逻辑分析仪支持拖放选择用于逻辑分析的连线,该接口无需改变设计,只需将编译设计的配置加入到配置文件中,标准逻辑分析仪就会检测到那些被连接到器件管脚的内部信号。
使用嵌入式逻辑分析仪SignalTapII,必须先建立SignalTapII文件(stp),该文件包括所有配置设置和捕获到的信号。设置好SignalTapII文件,就可以编译工程,对器件进行编译并使用SignalTapII采集和分析数据。使用SignalTapII采集信号数据的基本流程如图2所示:
2 实例分析
本文以基于FPGA的数据采集系统为例,具体说明嵌入式逻辑分析仪SignalTapII在系统调试过程中的应用。
2.1 硬件设计
数据采集系统以FPGA及高速AD转换器为核心,支持多路模拟信号的输入,实时的完成对输入信号的AD转换。系统硬件框图及其连接如图3所示。系统设计中,FPGA选用Altera公司CycloneⅡ系列EP2C5T144C8,AD转换器选用德州仪器公司的ADS7852[4,5],它是一款高速逐次逼近式AD转换器,具有8路输入、并行12位输出,内部带2.5V基准电压,外围接口电路简单,数据采样率高达500KHz。AIN0~AIN7为8路模拟输入,DB0~DB11为12位数字输出,A0~A2为8路模拟输入的地址选择;CLK为时钟输入(范围为200KHz到8MHz),BUSY为忙指示输出,CS、RD和WR分别为片选信号、读信号和写信号,均为低电平有效。
2.2 软件设计
软件设计的顶层设计文件如图4所示,主要包括采样时钟的产生和AD转换的实现两个模块。采样时钟模块通过主时钟分频得到,用于SignalTapII的数据采样。AD转换模块是通过FPGA实现AD7852的转换时序,顺利完成对输入模拟信号的转换,转换输出为12位并行数据。
2.3 SignalTapII文件配置
使用SignalTapII调试系统,在软件编译通过后添加“stp”文件,并对其进行设置,其设置界面如图5所示。
设置SignalTapII的基本流程[6,7]为
(1)设置被测信号。
使用Node Finder中的SignalTapII滤波器查找所有预综合和布局布线后的SignalTapII节点,添加要观察的信号。设计中主要观察AD采样的并行输出D11~D0是否正确,以及AD转换器的控制信号。
(2)设置采样时钟。
采样时钟决定了显示信号波形的分辨率,它的频率要大于被测信号的最高频率,否则无法正确反应被测信号波形的变化。SignalTapII在时钟的上升沿将被测信号存储到缓存。本设计中选用的采样频率与AD数据转换的频率相同,正好能完全反应信号波形变化。
(3)配置采样深度。
采样深度即采样点数,选择4K个数据。
(4)设置触发条件。
可以设定复杂的触发条件用来捕获相应的数据,以协助调试设计。选择高级触发条件,将触发设置为当采样输出大于或等于零时,系统即进行采样和数据波形的输出,触发设置如图6所示。
2.4 系统调试
完成“stp”文件的设置后,将系统连接好,保存该“stp”文件。整体编译工程,使用JTAG模式将程序及“stp”文件下载到FPGA中运行。系统测试时,在AD转换器的模拟输入端口AIN0端输入正弦信号,打开SignalTapII文件即可查看待测试的信号波形,波形显示形式可根据需要选择。该实例的输出信号如图7所示,从结果可以很直观的看到系统内部逻辑状况,判断在数据采集传输过程中的丢数、误码等现象,缩短了开发周期。
3 结束语
充分利用SignalTapII的易用性和可控性对系统进行调试,无需外挂复杂的测试设备,保证了信号的完整性,解决了系统软硬件调试的困难。通过数据采集系统的实例,证实了SignalTapII可大大提高系统的调试能力,缩短系统开发周期。
摘要：首先介绍了嵌入式逻辑分析仪SignalTapⅡ的基本原理和操作流程,并结合实例详细说明了SignalTapⅡ在系统调试过程中的应用。使用SignalTapⅡ对系统进行调试,解决了器件管脚不够或不方便外挂测试工具等软硬件调试的困难,避开了电路板测试时连接器引起的信号完整性问题。实验结果表明,该方法大大减少了系统调试、验证时间,缩短了设计周期,提高了系统设计的灵活性。
关键词：FPGA,嵌入式逻辑分析仪,SignalTapⅡ,系统调试
参考文献
[1]姚远,李辰.FPGA应用开发入门与典型实例[M].北京:人民邮电出版社,2010.5.
[2]王春花,黄厚宽,马聪.一种基于FPGA技术的虚拟逻辑分析仪的研究与实现[J].电子技术应用,2003,3:39-42
[3]孟令军,李娜.基于FPGA的内部逻辑在线测试技术研究[J].电测与仪表,2008,11:34-37
[4]赵顺珍.ADS7852与TLV5613在DSP中的接口设计[J].电子技术应用,2007,11:155-158
[5]刘艳玉,李德良,张飞龙,王长龙.ADS7852在双目测距中的应用[J].微计算机信息,2006,4-2:200-202
[6]阳习书,谢永乐.嵌入式逻辑分析仪在SOPC系统调试中的应用[J].现代科学仪器,2010,5:61-63