微处理器调试的历史，1980-2016

最后，您将 EPROM(s) 重新插入目标板并启动它以查看您的程序是否工作。如果您的程序没有按预期运行，那么您可以通过以下几个选项来调试代码：

代码检查： 在这种情况下，您将仔细检查您的代码以寻找错误。那些将使用任何调试工具视为编程技能失败的人今天仍在使用这种技术！您这样做的另一个原因是，由于硬件限制或成本原因，您无法使用以下技术。

LED： 这种技术今天仍在使用。如果目标系统上碰巧有 LED 或任何其他指示器，则可以通过修改代码以在代码中的重要位置发出状态信号来确定通过代码的路径。然后，您可以只查看 LED 以查看代码的进度（或通常没有进度），从而帮助您确定将注意力集中在哪里。 （另见当生活无法提供调试接口时，闪烁一个RGB LED .) 如果你有几个空闲的数字 IO 并且有幸能够使用逻辑分析器，你可以通过跟踪程序输出的状态（位置）来有效地实时跟踪代码中的路径。

在目标监视器上： 对于那些具有串行端口 (RS232) 和足够空闲 EPROM/RAM 以包含监控程序的目标板，您可以在汇编级别逐步执行代码并显示寄存器和内存位置的内容。监视器程序实际上是一个包含在您自己的代码中的低级调试器。在程序中的某个地方，您将跳转到监视器程序并开始调试。串口用于与监控程序交互，用户会发出诸如“s”来执行指令和“m 83C4,16”等命令来显示16个位置的内容，例如从地址0x83C4开始的内存。一旦代码按预期工作，最终的程序通常会在没有监视器的情况下构建。

在线仿真器： 对于那些负担得起的人来说，在线仿真器 (ICE) 是最终的调试工具。在某些方面，该工具提供的功能比当今开发人员提供的最先进的调试工具更多！ ICE 将用模拟 CPU 的电子设备替换目标系统中的 CPU。这些 ICE 工具很大（比台式 PC 大得多）而且非常昂贵——我们说的是数千美元。在这个时代，ICE 通常由 CPU 制造商或当时的主要工具公司之一（泰克、惠普/安捷伦、Microtek 等）设计，并且会包含模拟下的 CPU 的“绑定”版本.从字面上看，外挂式 CPU 将额外的内部信号传送到设备上的引脚，以便仿真器既可以控制 CPU，又可以对其内部操作获得额外的可见性。模拟器可以监视 CPU 执行的操作，并提供复杂的断点和跟踪功能，这将是当今许多开发人员羡慕的对象。也可以用包含在 ICE 中的仿真 RAM 替换目标内存区域（通常是 EPROM）。这让您可以将代码下载到仿真 RAM 中——开发过程中不再需要擦除和烧毁 EPROM——太棒了！

1982-1990
在 1980 年代，嵌入式开发人员发生了三个主要变化。首先是更多的集成 IC 开始出现，其中包含 CPU、PIC、UART、DMA 的组合——所有这些都包含在一个设备中。例如 Intel 80186/80188，它是 8086/8088 CPU（原始 IBM PC）的演变，Zilog Z180，它是 Z80（Sinclair Spectrum）的演变，以及 Motorola CPU32 系列（例如， 68302），是68000（Apple Lisa）的进化版。

第二个是 ICE 对开发人员来说变得更容易访问了。几家公司已经开始以比 CPU 制造商的系统低得多的成本制造 ICE 工具。许多这些公司没有使用绑定芯片。虽然这导致可用功能略有减少，但它极大地促进了低成本 ICE 产品的可用性。现在可以以不到 10,000 美元的价格购买 80186 的 ICE。

第三是不断提高的 CPU 时钟速度开始给 ICE 技术带来问题。这给 ICE 使用的布线系统带来了重大挑战，并开始导致仿真控制技术出现问题，该技术无法在如此高的速度下运行，而且成本会变得非常高（再次）。由于额外的片上连接会干扰芯片操作，因此 CPU 制造商也越来越不愿意创建 CPU 的绑定版本。解决这些问题的方法是在芯片上构建 CPU 调试控制电路。这允许单步、内存和寄存器访问以及断点技术以全 CPU 速度运行，但此时不提供跟踪，仍然需要访问设备外部总线接口引脚。

由于许多内部外设访问没有使用外部总线，因此该跟踪也不太实用。因此，只有外部访问是完全可见的，而内部外围访问是暗的。对片上调试 (OCD) 技术的访问要么通过专有接口技术——通常称为 BDM（后台调试模式）——要么通过标准 JTAG 接口，后者更传统地用于生产测试而不是调试。这些接口允许公司创建低成本的调试工具来控制 CPU 执行，而没有时钟速度限制。不同实现之间的特性略有不同；例如，有些允许调试工具在 CPU 执行时访问内存，而有些则不允许。

1990-2000
外部痕迹几乎消失了。 CPU 时钟速度的提高，加上内部 CPU 缓存的引入，使得外部跟踪几乎毫无用处。但是，为了诊断更复杂的程序缺陷，仍然需要能够记录 CPU 的执行路径。挑战在于如何使用片上逻辑来做到这一点（因此它可以以 CPU 全速运行），但如何使用尽可能少的引脚以可行的时钟速率将跟踪数据传输到芯片外。解决方案是将 CPU 的执行路径转换为压缩数据集，该数据集可以在片外传输并由调试工具捕获。然后该工具可以使用数据集来重建执行路径。人们意识到，如果调试工具可以访问执行的程序，则压缩可能是有损的。例如，如果仅输出非顺序程序计数器更改，则调试工具可以使用正在执行的程序的知识“填补空白”。 IBM 的 PowerPC、摩托罗拉的 ColdFire CPU、ARM 的基于 7TDMI 的内核等都基于这个概念实现了跟踪系统。

2000-2010
随着压缩核心跟踪数据集的引入，在片外传输数据集和/或使用相对较小的片上跟踪缓冲区来保存数据之间进行选择变得可行。在 2000 年代初期，各个供应商都在努力提高跟踪性能；例如，ARM 构建了嵌入式跟踪缓冲区 (ETB)，该缓冲区可通过 JTAG 访问且大小可配置以保存跟踪数据。这解决了必须以牺牲 SoC 中的硅面积为代价提供相对高速的片外跟踪端口（尽管仍远不及核心时钟速度）的问题。

在 2000 年代中期，嵌入式 CPU 设计人员开始实施多核系统。使用 ARM IP 的设计利用了 JTAG 技术，每个内核都出现在串行 JTAG 扫描链中。在实施内核电源管理之前，这不是问题，这导致内核在断电时失去其在 JTAG 串行扫描链上的存在。 JTAG 不支持从串行扫描链中出现和消失的设备，因此这给调试工具和 SoC 设计人员带来了复杂性。为了克服这个问题，ARM 创建了一个名为 CoreSight 的新调试架构。这允许单个基于 JTAG 的调试访问端口（JTAG 扫描链上的一个设备）提供对许多内存映射 CoreSight 组件的访问，包括系统中的所有 ARM 内核。现在，符合 CoreSight 的设备可以在不影响 JTAG 扫描链的情况下自由断电（您可以在这份新白皮书中阅读有关 CoreSight 技术的更多信息）。这项技术仍在今天设计的更现代且更复杂的基于 ARM IP 的系统中使用。

2010-
随着嵌入式处理器功能的增加——尤其是随着 64 位内核的出现——支持设备调试变得更加可行。以前，典型的调试系统在使用 JTAG/BDM 连接到目标系统的高性能工作站上使用调试工具来控制执行/跟踪。随着 Linux/Android 的广泛使用，内核增加了设备驱动程序以访问片上 CoreSight 组件。通过利用 perf 子系统，现在可以实现目标跟踪捕获和分析。

随着 ARM 嵌入式逻辑分析器 (ELA) 的推出，现在可以回到 ICE 时代，并可以访问复杂的片上断点、触发器和跟踪内部 SoC 信号——就像旧的一样80 年代初用于提供的外焊芯片。

今天，经过 40 年的创新，我们正处于调试新时代的风口浪尖，在这个时代，工程师可以对功能性 I/O 进行调试和跟踪，从而节省时间和金钱。推动在现有设备接口上执行调试不仅将提供更精简的解决方案，而且还将有助于将调试和跟踪能力提升到一个新的水平。就这样，我们在与 bug 的战争中开启了我们引人入胜的悠久历史的新篇章。