AM263P片上调试实战：CoreSight交叉触发与软件消息追踪解析-平芜编程栈

1. 项目概述

在嵌入式开发，尤其是汽车电子和工业控制这类对实时性和可靠性要求极高的领域，调试工作的复杂度和挑战性常常呈指数级增长。当你的系统里跑着多个Cortex-R5F实时内核、一个Cortex-M4安全协处理器，还有一堆高速外设和复杂的片上网络时，传统的“点个断点、单步走走”的调试方式就完全不够用了。你需要的是一套能够透视整个系统、捕捉瞬时状态、并能将不同模块的行为关联起来的“上帝视角”工具。这就是片上调试（On-Chip Debug, OCD）技术的核心价值所在。

AM263P作为德州仪器（TI）面向高性能实时控制推出的微控制器，其片上调试子系统是基于Arm CoreSight架构深度定制的，功能相当强悍。它不仅仅提供了标准的JTAG接口让你能连接调试器，更内置了一整套复杂的事件触发与追踪基础设施。简单来说，这套系统允许你将系统里发生的任何“事件”（比如某个特定的中断触发、某个内存地址被写入、或者某个CPU进入了调试状态）与一个你预设的“动作”（比如让另一个CPU暂停、开始记录追踪数据、或者触发一个外部信号）关联起来。这种“交叉触发”的能力，是解决多核协同、硬实时系统偶发性故障的利器。同时，其软件消息追踪功能，允许应用程序在不显著影响性能的前提下，向调试器输出结构化的日志和性能标记，为分析系统行为提供了宝贵的数据流。

本文将深入AM263P的调试子系统，抛开手册里那些零散的寄存器描述，从实际调试场景出发，为你拆解三个核心机制：JTAG边界扫描用于硬件连通性测试，CoreSight交叉触发网络用于实现精准的、跨模块的调试控制，以及软件消息追踪用于获取丰富的运行时上下文信息。我会结合具体的配置步骤、寄存器操作细节以及在实际项目中踩过的坑，让你不仅能看懂手册，更能真正用起来这套强大的调试工具。

2. 调试基础设施深度解析：不止于连接

在深入那些高级功能之前，我们必须先打好地基。AM263P的调试访问是建立在标准的Arm CoreSight架构之上的，这意味着它兼容主流的调试探头（如TI的XDS系列、Lauterbach的Trace32等）。但仅仅“连得上”是远远不够的，理解其下的硬件逻辑和访问路径，是高效利用所有高级功能的前提。

2.1 JTAG边界扫描与复位管理：硬件诊断的基石

很多人把JTAG（Joint Test Action Group）接口仅仅看作是一个下载程序和设断点的通道，这大大低估了它的价值，尤其是在AM263P这样的复杂SoC上。

2.1.1 边界扫描的实战价值

AM263P支持IEEE 1149.1和1149.6标准的边界扫描。这个功能在项目生命周期中的两个阶段极其有用：

硬件原型调试阶段：当第一版PCB回来，芯片焊上去却发现连不上调试器时，边界扫描是你的第一道诊断工具。你可以通过它非侵入性地测试所有JTAG链路上的器件（包括AM263P本身、可能的CPLD、Flash等）的连通性，快速定位是虚焊、短路还是信号完整性问题。
生产测试与故障分析：在量产中，可以利用边界扫描对板级互联（如芯片间的GPIO连接、存储器总线）进行自动化测试，覆盖那些传统在线测试（ICT）探针无法触及的节点。

TI会为AM263P提供对应的BSDL（Boundary Scan Description Language）文件。在使用时，你需要将其导入到你的边界扫描测试软件（如TI的Smart Debug Tool或第三方工具）中。操作流程通常是：通过调试器激活芯片的JTAG TAP（Test Access Port）控制器，然后发送一系列预定义的测试向量，通过扫描链的输入/输出捕获结果，与预期值比对。一个常见的坑是：务必确认你使用的BSDL文件版本与芯片的硅版本（Revision）完全匹配。不同版本的芯片其引脚边界扫描单元的定义可能有细微差别，用错文件会导致测试结果完全错误。

2.1.2 独立于系统复位的调试域

这是AM263P调试子系统一个非常关键的设计，手册里称之为“Reset isolation”和“Configuration independence”。我用大白话解释一下：

调试配置独立：所有调试相关的逻辑（如交叉触发矩阵CTI、追踪源ETM/STM、追踪缓冲区ETB）是通过一个独立的、专用于调试的片上互联（Debug Interconnect）进行配置的。这个互联与主SoC的数据路径是分开的。
关键逻辑抗复位：追踪数据路径和关键的调试配置逻辑，对“热复位”（Warm Reset）不敏感。

这意味着什么？想象一个场景：你的应用程序跑飞了，触发了看门狗，导致整个系统热复位。在普通的芯片上，调试器连接可能会断开，所有断点、观测点设置都会丢失。但在AM263P上，由于调试配置是独立的且抗复位，即使主应用CPU被复位重启，调试会话依然可以保持。你仍然可以连接调试器，读取刚才发生故障时的追踪缓冲区数据，或者检查调试状态寄存器。这对于诊断那些“一复位就消失”的偶发性死机或数据损坏问题，是决定性的优势。

2.1.3 Power-AP：系统状态的终极控制阀

这是TI在CoreSight架构上的一个很有价值的扩展。CoreSight定义了标准的调试访问端口（DAP），包括MEM-AP（内存访问）、JTAG-AP等。TI增加了一个Power-AP。这个AP不是用来访问内存的，而是专门用于访问和控制系统的电源、复位和时钟状态。

手册里提到了几个关键寄存器，如SYSTEMRESET_SPREC、WIRREG_SPREC等。它们不是内存映射的，意味着你不能通过写0xXXXX_XXXX这样的地址来访问。你必须通过调试器的“表达式窗口”或命令行，直接使用寄存器名来操作。例如，在Code Composer Studio (CCS)的脚本控制台或Lauterbach的TRACE32命令中，你可以直接执行：

// 这是一个概念示例，具体命令取决于调试器 system.register.PWRAP_SPREC = 0x1; // 发起系统复位

Power-AP的典型应用场景包括：

强制系统复位：当应用程序完全死锁，甚至无法响应NMI时，通过Power-AP可以发起一个干净的复位。
调试状态下的时钟控制：为了降低功耗或稳定调试环境，可以临时关闭或调整某些时钟域。
复位序列调试：精确控制复位释放的时序，用于调试复杂的上电/下电序列问题。

实操心得：在编写低功耗或启动代码时，我强烈建议你利用Power-AP来验证你的电源管理序列。你可以通过调试器手动操作这些寄存器，模拟不同的复位和时钟场景，观察系统的反应，这比反复烧录代码测试要高效得多。

2.2 CoreSight交叉触发网络：事件驱动的调试中枢

如果说调试访问端口是“手和脚”，那么交叉触发网络就是整个调试系统的“大脑和神经网络”。它负责监听系统中各处发生的“事件”，并按照你的配置，执行相应的“动作”。AM263P实现了一个四通道的、符合CoreSight标准的可编程交叉触发网络。

2.2.1 核心概念：事件与动作的映射

你可以把每个交叉触发通道（CTI, Cross Trigger Interface）想象成一个可编程的逻辑单元。它有一组输入（Triggers In）和一组输出（Triggers Out）。

事件（输入）：可以是“CPU进入了调试状态（Halted）”、“ETM发出了一个追踪触发信号”、“某个特定的VIM中断发生了”，甚至是“软件通过写STM寄存器产生了一个事件”。
动作（输出）：��以是“向某个CPU发送外部调试请求（EDBGRQ）使其暂停”、“让ETM开始或停止记录”、“触发一个系统级的中断”，或者“让追踪缓冲区（ETB）开始捕获数据”。

你的工作就是通过配置CTI内部的通道使能寄存器和映射寄存器，来定义“当事件A发生时，就执行动作B”。这种映射关系可以是“与”、“或”等逻辑组合。

2.2.2 AM263P各模块的触发连接详解

手册中的表格（Table 14-5 至 14-11）列出了每个模块（R5F, M4, STM, DEBUGSS）具体的输入输出连接。我们以最常用的Cortex-R5F的CTI为例，拆解几个关键点：

R5F CTI 输入（Table 14-5）:
- [7]: 来自VIM（向量中断管理器）的中断源。这是一个多路选择器（Mux），你可以通过配置MSS_CTRL.R5SS*_CTI_TRIG_SEL寄存器，选择256个VIM中断中的任意一个作为触发事件。这功能极其强大。比如，你可以配置当“CAN总线错误中断”发生时，立刻触发一个调试动作。
- [6]: 来自ETM的触发。用于将ETM内部的复杂触发条件（如“当程序计数器在0x8000到0x9000范围且加载了特定地址的数据”）导出到交叉触发网络。
- [1]: 来自PMU（性能监控单元）的中断。当性能计数器溢出时，可以触发调试。
- [0]: 核心调试触发。当R5F内核因断点或观测点而进入调试状态（Halted）时，此事件自动产生。
R5F CTI 输出（Table 14-6）:
- [7]:DBGRESTART。向CPU发送重启请求。可以用于在调试暂停后，让CPU恢复执行。
- [3]: 触发一个VIM中断。这实现了“调试事件触发应用层中断”。例如，当追踪缓冲区快满时，触发一个中断让CPU去处理数据。
- [0]:EDBGRQ。外部调试请求。这是最常用的动作——让另一个CPU暂停。例如，配置当CPU0访问某个非法内存地址（通过ETM事件）时，通过交叉触发网络向CPU1发送EDBGRQ，让CPU1也暂停，从而捕捉多核间的协同问题。

2.2.3 配置流程与示例

假设我们想实现这样一个调试场景：当R5FSS0_Core0发生特定的VIM中断（比如中断号100）时，立即暂停R5FSS1_Core1。

选择事件源：我们需要使用R5FSS0_Core0的CTI。将其输入通道[7]配置为接收VIM中断100。
- 找到寄存器MSS_CTRL.R5SS0_CTI_TRIG_SEL.TRIG0（假设Core0对应TRIG0）。将该寄存器设置为100。这样，VIM中断100就被路由到了R5FSS0_Core0 CTI的输入7。
在CTI内部建立映射：我们需要在R5FSS0_Core0的CTI内部，将输入事件7映射到一个输出动作。
- 访问R5FSS0_Core0的CTI寄存器（通过调试器的内存窗口，地址通常在0x5A0A_0000附近，需查具体手册）。
- 使能输入通道7：设置CTIINEN[7] = 1。
- 假设我们使用通道0（Channel 0）来传递这个触发。设置CTIINEVENT[7]的值为0x1（表示输入7映射到通道0）。
- 设置输出动作：我们希望触发一个输出。设置CTIGATE寄存器，确保对应通道的输出门控是打开的。然后，将CTIOUTEN[0]（对应输出0，即EDBGRQ）设置为1，并将CTIOUT[0]映射到通道0。
在目标CTI接收并动作：我们需要在R5FSS1_Core1的CTI上接收这个通道事件，并触发暂停。
- 访问R5FSS1_Core1的CTI寄存器。
- 使能输入通道0（用于接收来自网络的通道0事件）：设置CTIINEN[0] = 1。
- 将输入0映射到其内部的某个通道，比如通道1：CTIINEVENT[0] = 0x2。
- 使能输出动作：将其输出0（EDBGRQ）映射到通道1：CTIOUTEN[0] = 1,CTIOUT[0] = 0x2。
连接网络：最后，需要将两个CTI的通道0在系统级的交叉触发矩阵（CTM）中连接起来。这通常需要配置一个叫做CTM（Cross Trigger Matrix）的组件，将源CTI的通道0输出，连接到目标CTI的通道0输入。AM263P的CTM配置寄存器位于调试子系统空间。

注意事项：配置交叉触发时，时序很重要。如果事件是瞬时脉冲，而动作端CTI没有及时使能，可能会错过触发。一个稳妥的做法是，先配置好所有CTI的输入输出映射，最后再统一使能各个CTI的通道门控（CTIGATE）。另外，调试器软件（如CCS）通常提供图形化界面来配置交叉触发，这比手动写寄存器要方便和可靠得多，建议优先使用。

3. 软件追踪与系统级调试能力

当你的系统在高速运行，断点会严重干扰实时性时，追踪（Trace）就成了不可或缺的工具。AM263P提供了两种主要的追踪方式：基于硬件的指令追踪（ETM）和基于软件的消息追踪（STM）。

3.1 软件消息追踪：低开销的“printf”调试

指令追踪（ETM）虽然强大，但它记录的是每一条执行的指令，数据量巨大，并且需要昂贵的追踪探头和高速接口。而软件消息追踪（STM）则是一种折中且极其实用的方案。AM263P集成了一个符合MIPI STPv2标准的CoreSight STM模块。

3.1.1 STM的工作原理

STM在系统地址空间中开辟了一段专用的内存映射区域（Aperture）。如表14-12所示，AM263P为不同的发起者（Initiator）分配了不同的16MB地址窗口。例如：

0x0000_0000 - 0x00FF_FFFF: 分配给R5SS0_CORE0_AXI_W
0x0100_0000 - 0x01FF_FFFF: 分配给R5SS0_CORE1_AXI_W
以此类推，还有HSM、PRU等。

当你的软件（运行在R5FSS0_Core0上）想输出一条调试消息时，它不需要调用任何复杂的驱动API，只需要像写普通内存一样，向它专属的STM地址窗口（例如0x0008_0000）执行一次写操作。STM硬件会捕获这次写事务，将其打包成STP协议的数据包，然后通过CoreSight追踪基础设施发送出去。

3.1.2 在代码中的使用示例

在C代码中，使用STM可以简单到定义一个宏：

// 假设STM基地址为0x5000_0000，R5SS0_CORE0的偏移为0 #define STM_PORT0_BASE (*(volatile uint32_t *)(0x50000000)) void log_message(uint32_t id, uint32_t data) { // 将ID和数据组合写入STM端口。ID可以用于在解码端区分消息来源或类型。 STM_PORT0_BASE = (id << 16) | (data & 0xFFFF); // 或者更常见的，直接写入你想发送的任何32位值 // STM_PORT0_BASE = your_debug_value; }

然后，在你的应用代码中，可以在关键路径插入log_message(TASK_START_ID, get_tick_count());这样的语句。其开销远低于传统的UART输出，因为只是一次内存写操作，不涉及中断、上下文切换或外设配置。

3.1.3 配置与数据捕获

使能STM：通过调试器或启动代码，配置STM控制寄存器，使其开始捕获数据。
配置追踪路由：STM产生的追踪数据需要被路由到“追踪接收器”（Sink）。如图14-4所示，AM263P有两个接收器：CS-ETB（片上34KB缓冲区）和TPIU（通过引脚输出到外部追踪探头）。你需要使用CoreSight Trace Replicator (CSREP)来配置数据是流向ETB、TPIU还是两者。
选择接收器：
- 使用CS-ETB：适合短时间、高频率的追踪。配置简单，数据直接在芯片内循环存储。当缓冲区满时，可以配置触发中断，让CPU将数据读出到系统内存。缺点是容量有限。
- 使用TPIU：需要连接支持Trace的调试探头（如XDS560v2 Pro Trace��。数据通过专用引脚（通常是LVCMOS）实时输出到探头，再由探头上传到PC。优点是容量无限（取决于探头存储），适合长时间追踪，但需要占用引脚和额外硬件。

实操心得：STM是进行系统级性能分析和事件序列还原的利��。例如，在调度器切换任务时打点，在中断服务程序入口/出口打点，在获取/释放锁时打点。将这些时间戳和事件ID收集起来，在PC端用工具（如TI的CCS Timeline或ARM DS-5 Streamline）进行可视化，可以清晰地看到CPU利用率、任务调度时序、中断延迟等，对于优化系统性能、发现优先级反转等问题有奇效。一个关键技巧是：给不同类型的消息分配不同的ID，并在解码端用不同颜色显示，这样在时间线上可以一目了然。

3.2 调试感知外设：让外设与CPU调试状态联动

这是一个非常贴心的功能，手册中称为“Debug Aware Peripherals”。某些外设（如MCAN、ePWM、ECAP等）可以配置为感知其关联CPU的调试状态。

3.2.1 功能与配置

以ePWM模块为例，它通常用于产生精密的PWM波形控制电机。如果CPU因为触发断点而暂停（Halted），而ePWM计数器还在继续运行，可能会导致电机失控，非常危险。AM263P允许你通过配置CONTROLSS_CTRL.EPWM*_HALTEN寄存器，将某个ePWM模块与一个特定的R5F CPU绑定。

当该CPU进入调试暂停状态时，硬件会自动暂停与之绑定的ePWM模块的计数器。CPU恢复运行时，计数器也自动恢复。这个功能完全由硬件实现，无需软件干预，极大地增强了在调试实时控制系统时的安全性。

配置方法很简单：找到你想要控制的外设对应的*_HALTEN寄存器（表14-13列出了大部分），写入你想要关联的CPU编号（例如，对于R5FSS0_Core0，可能写入0）。具体的位域定义需要参考芯片的寄存器手册。

3.2.2 应用场景与注意事项

安全关键调试：在调试电机驱动、电源转换等应用时，务必启用相关PWM和比较器模块的Halt感知功能。
通信调试：调试CAN或LIN通信时，如果CPU暂停，启用MCAN*_HALTEN或LIN*_HALTEN可以让通信控制器也进入安全状态，避免总线错误。
注意事项：不是所有外设都支持此功能。需要仔细查阅手册。另外，这个绑定关系是静态配置的，通常在系统初始化时设置好，运行时不能动态切换。

4. 追踪基础设施实战指南

理解了各个组件后，我们需要把它们串联起来，搭建一个完整的追踪系统。图14-4展示了AM263P的追踪基础设施全景。

4.1 追踪数据流全景

追踪源：数据从哪里来？
- ETM（4个R5F内核）：提供指令流追踪，能重建程序执行历史。
- STM：提供软件插入的标记和消息。
- HSM M4 ITM：M4内核的Instrumentation Trace Macrocell，类似于STM，但专属于M4。
追踪聚合与路由：
- CSTF：多个追踪源（如4个R5F的ETM）的数据流会先汇入一个CoreSight Trace Funnel进行合并，形成一个单一的追踪流。
- CSREP：这是数据流的分路器。你可以编程控制它将追踪流复制到两个目的地（ETB和TPIU），或者只选择其中一个。这是配置追踪目的地的关键。
追踪接收器：数据到哪里去？
- CS-ETB：片上34KB SRAM缓冲区。容量有限，适合捕获触发前后的短时间高密度事件。需要软件定期读出数据以防覆盖。
- TPIU：将追踪数据格式化并通过芯片引脚输出到外部调试探头。这是进行长时间、无丢失追踪的标准方式。

4.2 典型配置步骤

假设我们想同时捕获R5FSS0_Core0的指令追踪和所有R5F内核的STM消息，并输出到外部探头。

使能追踪源：
- 通过调试器，配置R5FSS0_Core0的ETM控制寄存器，使其开始生成追踪数据。通常需要设置触发条件（如从某个地址开始追踪）、使能追踪。
- 配置STM控制寄存器，使能所有需要的STM端口（例如，使能R5FSS0_CORE0_AXI_W和R5FSS0_CORE1_AXI_W的窗口）。
配置CSREP路由：
- 访问CSREP寄存器。找到控制输出路由的寄存器（通常称为ATBIDR或CTRL寄存器）。
- 设置路由规则。例如，将所有追踪数据（ID可能代表ETM或STM）同时路由到ETB和TPIU，或者只路由到TPIU。对于长时间追踪，我们选择只路由到TPIU。
配置TPIU：
- 设置TPIU的协议格式（通常为Sync Trace Protocol）、端口宽度（1-bit, 2-bit, 4-bit，取决于硬件连接）。端口宽度越大，数据传输率越高，但占用引脚越多。
- 配置TPIU的时钟预分频器，使其输出速率与调试探头的接收能力匹配。
配置调试探头：
- 在CCS或Trace32中，设置追踪会话参数：选择TPIU作为源，设置正确的时钟频率、端口宽度。
- 建立连接并开始捕获。

4.3 常见问题与排查技巧

问题：连接了追踪探头，但CCS里看不到任何追踪数据。
- 检查1：电源和时钟。确认芯片已上电，并且核心时钟（特别是调试和追踪模块所在的时钟域）已经正确配置并运行。很多追踪模块在低功耗模式下会被关闭。
- 检查2：引脚复用。确认用于TPIU追踪输出的引脚（如TRC_DATA0,TRC_CLK）没有被复用作其他功能（如GPIO）。检查芯片的PinMux配置。
- 检查3：TPIU配置。确认TPIU已使能，并且协议、端口宽度配置与探头设置完全一致。一个常见的错误是芯片端配置为4-bit模式，而探头端设置为1-bit模式。
- 检查4：CSREP路由。确认追踪数据确实被路由到了TPIU，而不是只去了ETB或直接被禁用。
问题：STM消息在时间线上显示乱码或错位。
- 检查1：STM端口地址。确保你的软件写入的地址完全匹配该CPU核心分配的STM地址窗口。写错了地址，数据不会被STM捕获。
- 检查2：数据对齐。STM通常要求32位对齐的写操作。确保你的写操作是uint32_t类型，并且地址是4字节对齐的。
- 检查3：解码配置。在CCS的Trace分析视图中，需要正确设置STM的“刺激端口”（Stimulus Port）编号和消息格式，才能正确解析原始数据。
问题：交叉触发不工作，预期暂停的CPU没有暂停。
- 检查1：CTI和CTM使能。除了配置映射关系，务必确认源CTI、目标CTI以及中间的CTM组件都已经通过其控制寄存器使能（CTICONTROL寄存器中的Enable位）。
- 检查2：事件类型。确认你选择的事件源确实能产生脉冲信号。例如，某些状态位是电平型的，可能不适合直接作为CTI的触发输入。
- 检查3：调试器干扰。有些调试器在连接时，会默认修改一些调试相关的全局设置。确保你的手动配置没有被调试器的自动配置覆盖。可以在脚本中最后执行你的交叉触发配置。
问题：使用ETB时，缓冲区很快被覆盖，抓不到完整的触发前后信息。
- 策略：利用交叉触发！配置一个触发条件（如程序计数器到达某个函数入口），将该事件同时连接到两个动作：1) 开始ETM追踪；2) 延迟一段时间后，停止ETM追踪。这样，ETB只会记录你感兴趣的那一段代码，避免了缓冲区被无关代码填满。这需要精细地配置ETM本身的触发和范围控制寄存器。

5. 从理论到实践：一个多核调试场景的完整配置案例

让我们设计一个综合性的调试场景，运用上述所有功能：目标：调试R5FSS0_Core0和R5FSS1_Core0之间的一个数据共享竞争问题。怀疑是Core0在写共享内存时，Core1在读，导致数据不一致。

步骤：

设置观测点：在调试器中，在共享内存的关键变量地址上设置一个“写”观测点。当Core0写入该地址时，Core0会进入调试状态（Halted），并产生一个CORE:DBGTRIGGER事件（R5F CTI输入[0]）。
配置交叉触发：
- 配置R5FSS0_Core0的CTI：将输入事件0（DBGTRIGGER）映射到交叉触发网络的某个通道（例如通道1）。
- 配置R5FSS1_Core0的CTI：监听交叉触发网络的通道1。当收到事件时，触发输出动作0（EDBGRQ），使Core1也立即暂停。
- 这样，一旦Core0因为写共享变量而暂停，Core1也会被同步暂停，我们可以同时检查两个核的上下文、调用栈和内存状态，看看Core1是否正在读取一个不完整的值。
启用软件追踪：在两个核心的代码中，在访问共享内存的前后，插入STM消息。例如：
- Core0写之前：STM_PORT = 0xA001(ID表示“Core0写开始”)
- Core0写之后：STM_PORT = 0xA002(ID表示“Core0写完成”)
- Core1读之前：STM_PORT = 0xB001(ID表示“Core1读开始”)
- Core1读之后：STM_PORT = 0xB002(ID表示“Core1读完成”)
配置追踪捕获：
- 使能两个核心的STM端口。
- 配置CSREP，将STM数据路由到TPIU进行输出。
- 在调试器中开始追踪捕获。
执行与复现：让系统全速运行。当竞争条件发生时，观测点被触发，两个核心同时暂停。此时，在调试器中：
- 查看两个核心的暂停位置和寄存器值。
- 停止追踪捕获，分析STM消息的时间线。你可以精确地看到Core0的“写完成”和Core1的“读开始”之间的时序关系，从而确认是否存在竞争。
安全措施：由于我们在调试实时任务，为了防止PWM输出异常，我们提前配置了相关ePWM模块的HALTEN寄存器，将其绑定到对应的CPU。这样当CPU暂停时，电机控制信号会自动保持安全状态。

这个案例展示了如何将边界扫描（确保硬件连接）、交叉触发（同步调试状态）、软件追踪（记录时间序列）和调试感知外设（保证安全）组合起来，形成一个强大的、针对复杂问题的调试方案。AM263P的片上调试架构为这类深入的系统级诊断提供了坚实的硬件基础。掌握这些工具，能让你在面对最棘手的嵌入式系统 bug 时，拥有抽丝剥茧、直击根源的能力。