在嵌入式系统中，外设无响应、裸机程序异常退出或处理器与可编程逻辑之间的交互错误，经常无法通过串口日志直接定位。复位系统可能恢复运行，但也会清除故障发生时的寄存器、内存和执行状态。因此，调试的步通常是保留现场，再根据状态变化还原问题。
本文介绍 AMD Vitis Unified IDE 中几项常用的调试能力，包括 Memory Inspector、PS PL Cross Trigger、PS Trace 和 Register Inspector，并说明如何将这些功能与 XSDB、User Managed Mode 和 VS Code 工作流配合使用。
嵌入式系统调试需要保留哪些信息
外设异常时，处理器通常仍在运行，开发者可以暂停程序并检查相关配置。整机崩溃时，处理器可能已经进入异常状态，控制台也可能没有任何输出。如果立即复位，程序计数器、寄存器值、内存内容和崩溃前的执行路径都会丢失。
有效的排查过程需要回答三个问题：故障发生时系统处于什么状态，哪些数据发生了变化，以及处理器如何执行到当前状态。Vitis Unified IDE 提供的内存检查、交叉触发和处理器跟踪功能，可以分别提供这些信息。
结合命令行自动化和 IDE 分析
XSDB 是底层硬件调试的重要入口。开发者可以通过 hw_server 连接目标板，配置 FPGA，并调试嵌入式软件。Python-XSDB 将这些操作引入 Python 脚本，适合自动执行板卡启动、初始化和回归测试，也便于控制各个步骤。
脚本适合处理可重复的操作，但仅查看文本输出往往难以分析寄存器、内存或执行轨迹。一种常见做法是先用 XSDB 或 Python-XSDB 完成初始化和测试，在发现异常值、外设故障或可疑执行路径后，再使用 Vitis Unified IDE 检查相关状态。这种方式结合了脚本的自动化能力和 IDE 的可视化分析能力，可以更快速、直观地定位问题。这种方式结合了脚本的自动化能力和 IDE 的可视化分析能力，可以更快速、直观地定位问题。
使用 Memory Inspector 检查寄存器和内存
嵌入式外设通常通过内存映射寄存器进行控制。设备不工作时，应首先检查时钟、复位、使能位、工作模式和中断状态，并将实际寄存器值与设计预期逐项比较。对于数据通路问题，还需要检查缓冲区、DMA 状态和指针值。
Memory Inspector 可以查看和修改目标系统中的内存，也可以固定当前视图、保存快照并导出指定地址范围。处理器软件、PL、DMA 和其他硬件 IP 可能同时修改同一片内存。保存故障前后的快照后，开发者可以直接比较发生变化的字节或寄存器，从而检查异常写入、缓冲区覆盖、DMA 传输错误和指针问题。
Memory Inspector 支持以十六进制、十进制、二进制或 ASCII 格式解析数据，便于将原始内存内容与字符串、计数器和应用数据对应起来。指定的内存区域还可以导出为 Motorola S-Record 文件。该格式同时保存地址和数据，可用于重新加载现场、比较不同运行结果，或交由其他工程师继续分析。
图 1 Memory Comparison 显示两次快照之间的差异
排查 DMA 缓存一致性问题
DMA 缓存一致性问题常表现为程序逻辑正确，但应用读取的数据没有更新。DMA 将新数据直接写入 DDR，而 CPU 仍从缓存中读取旧副本，因此 CPU 看到的内容可能与 DDR 中的实际数据不同。
可以先用 Memory Inspector 检查 DDR 缓冲区，再与 CPU 读取的内容进行比较。如果确认存在不一致，可针对相应缓存范围执行失效操作，例如调用 Xil_DCacheInvalidateRange()，然后重新读取并比较结果。这种方法能够验证问题是否来自缓存一致性，也能确认修改是否生效。
使用 PS PL Cross Trigger 对齐软硬件状态
运行在 APU 或 RPU 上的软件经常与 PL 中的逻辑并行工作。若分别暂停软件和硬件，两侧采集到的状态可能不属于同一个故障时刻。例如，当软件检测到输出数据损坏后再暂停 CPU，PL 中的状态机可能已经继续运行。
PS-PL Cross Trigger 使用 Arm Embedded Cross Trigger 机制连接不同调试域。开发者可以设置由 PL 条件触发 CPU 暂停，从而在同一时间点保留处理器寄存器、内存和 PL 内部信号。该机制也可以同步处理器状态与跟踪采集，或协调多个 CPU 进入调试状态。这样获得的软硬件状态具有一致的时间基准，更适合分析跨 PS 和 PL 的问题。
图 2 PS PL Cross Trigger 配置
使用 PS Trace 分析无日志崩溃
On-chip Trace 已在 26.1 版本中正式发布，而 Off-chip Trace 在 26.1 版本中属于抢先体验功能。
对于没有日志的裸机崩溃，断点和变量查看只能提供暂停时刻的信息，通常无法说明处理器如何到达故障位置。PS Trace 将处理器跟踪数据集成到 Vitis 调试流程，用于分析崩溃前的执行路径。
PS Trace 根据处理器生成的硬件跟踪数据还原指令执行顺序，并按时间线显示结果。开发者可以从故障位置向前查看，同时对照 C 源码和反汇编，分析异常、死循环或中断频繁触发等问题。
在 Vitis Unified IDE 2026.1 中，On-chip PS Trace 已作为 Production 功能提供。开发者可以在启动配置中启用该功能，并通过起始和停止断点限定采集范围。跟踪数据保存在片上缓冲区中。如果 CPU 在到达停止断点前崩溃，也可以手动导出跟踪数据并在 IDE 中查看。
对于需要更长采集时间的场景，可使用 2026.1 Early Access 阶段的 Off-Chip Trace。使用前，需要在 Vitis > New Feature Preview 中启用该功能。Trace Port Interface Unit 将 ETM 或 PTM 跟踪包实时发送到 SmartLynq+ 等外部设备，避免受到片上缓冲区容量的限制。该方式适合分析低频故障、复杂控制流和长时间运行的应用。对于需要更长采集时间的场景，可使用 2026.1 Early Access 阶段的 Off-Chip Trace。使用前，需要在 Vitis > New Feature Preview 中启用该功能。Trace Port Interface Unit 将 ETM 或 PTM 跟踪包实时发送到 SmartLynq+ 等外部设备，避免受到片上缓冲区容量的限制。该方式适合分析低频故障、复杂控制流和长时间运行的应用。
图 3 PS Trace 时间线以及源码与反汇编视图
结合 PS Trace 和 Register Inspector 分析 Crash 问题
PS Trace 用于还原处理器的执行路径，Register Inspector 用于检查故障时的处理器状态。崩溃快照可包含程序计数器、栈指针、CPSR 标志位和其他处理器寄存器。这些数据可以导出，用于比较不同运行结果或与团队共享。
以图4为例，PS Trace 的一条记录显示 CPU 正在从内存加载数据。仅查看该指令还不能确定崩溃原因。Register Inspector 显示，用作加载地址的寄存器包含无效值。结合执行记录和寄存器状态，可以先确定直接故障位置，再继续追查该指针值的来源。
图 4 崩溃示例
Vitis Unified IDE 2026.1 已对 R52、A78、A72、A53 和 R5 裸机目标提供 On-chip Trace 的 Production 支持。R52 和 A78 的 Off-chip Trace 在 2026.1 处于 Early Access 阶段，计划在 2026.2 转为 Production。Linux 平台已有相应的跟踪工具，Vitis 对 Linux 的专门支持计划在后续版本提供。
图 5 Register Inspector 显示处理器状态
将调试能力接入现有开发流程
工程无需在 Vitis Unified IDE 中创建。通过 User Managed Mode，开发者可以继续使用现有的 Makefile、Python 脚本或二进制文件，并在裸机、Linux 和系统级设计中直接使用 Vitis 进行调试和仿真，从而保留原有的构建流程。
对于使用 VS Code 的开发者，Vitis Debugger Extension for VS Code 在 2026.1 以 Early Access 形式支持 C/C++ 裸机应用，提供源码断点、单步调试、变量和处理器寄存器查看、监视表达式以及调用栈导航等功能。版本仍通过 XSDB 脚本完成硬件初始化；计划在 2026.2 版本中通过 launch.json 自动完成目标启动。
对于 Zephyr 开发，2026.1 支持在 Vitis 环境中创建、配置和构建项目，再通过 User Managed Mode 进行调试。后续版本计划将完整的调试流程进一步集成到 Zephyr 工作台。
同一路线图还包括 Zephyr IDE Extension 和 Vitis Function Simulation 调试。在 2026.1 中，Zephyr 项目可以在 Vitis 环境内创建、配置和构建，再通过 User Managed Mode 进行调试；后续版本计划将完整调试流程进一步集成到 Zephyr 工作台。Vitis Function Simulation 调试用于在部署到硬件前进行功能级仿真和验证。
图 6 User Managed Mode 启动配置
图 7 在 VS Code 中使用 Vitis 调试
调试方法总结
这些功能提供不同类型的调试信息。Memory Inspector 用于检查寄存器和内存变化；PS-PL Cross Trigger 用于同步触发处理器和 PL 调试事件，从而捕获同一时刻的软硬件状态；Register Inspector 用于读取或者更新寄存器状态，以获取处理器状态；PS Trace 用于还原到达该状态之前的执行路径。XSDB、User Managed Mode 和 VS Code 扩展则提供不同的接入方式。
实际排查时，应先保存故障现场，再比较异常发生前后的状态变化。对于处理器异常，需要将执行路径与寄存器值结合分析。完成修改后，应使用相同的触发条件和观察方法重新测试，以确认问题已经解决。
