嵌入式实时调试利器：PC Trace原理、配置与实战应用解析-平芜编程栈

1. 嵌入式实时分析与诊断（ERAD）与PC Trace核心价值解析

在嵌入式系统，尤其是像TI C2000系列这样的实时微控制器开发中，最头疼的问题往往不是代码写不出来，而是代码跑起来后，你根本不知道它在“想”什么。传统的调试手段，比如打断点、单步执行，在分析复杂的时间序列问题、偶发的执行流异常或者精确的性能瓶颈时，常常显得力不从心。你一暂停CPU，整个实时系统的时序就全乱了，问题可能就此消失，这就是所谓的“海森堡测不准原理”在嵌入式调试中的体现。

这时，嵌入式实时分析与诊断（ERAD）模块的价值就凸显出来了。它就像给运行中的CPU装上了一套“黑匣子”和“性能监测仪表盘”。ERAD是一组紧密耦合在CPU总线上的硬件外设，能够在不停止CPU执行、不侵入代码的前提下，实时监控系统行为。其中，程序计数器追踪（PC Trace）模块又是这个“黑匣子”中最核心的“飞行记录仪”。它的任务不是记录每一行代码（那会产生海量数据），而是精准地记录程序执行流中的“转折点”——也就是所有非顺序执行的事件，比如函数调用、中断跳转、条件分支、循环跳出等。通过记录这些跳转的源地址和目标地址对，我们就能在事后像看地图一样，完整地重构出代码的执行路径。

对于TMS320F28003x这类用于数字电源、电机控制等对实时性和可靠性要求极高的场景的MCU来说，PC Trace的意义非凡。你可以用它来验证中断服务程序（ISR）是否在预期的时间内被触发和执行完毕，分析最坏情况执行时间（WCET），定位那些导致系统偶尔卡顿的、难以复现的异常跳转，甚至监测堆栈是否发生了溢出。它把调试从“猜测-打断点-观察”的被动模式，升级到了“设定条件-全速运行-事后分析”的主动观测模式。接下来，我们就深入这个“黑匣子”内部，看看PC Trace到底是怎么工作的，以及如何把它用起来。

2. PC Trace模块工作原理与架构深度拆解

要玩转PC Trace，不能只停留在调用API的层面，必须理解它的硬件架构和工作机制，这样才能在复杂场景下做出正确的配置和问题排查。

2.1 核心工作机制：捕获“不连续点”

PC Trace模块的核心任务非常明确：捕获程序计数器（PC）的不连续点。什么是不连续点？简单说，就是PC值不是简单地+1（顺序执行）的情况。这主要包括：

分支指令：B（跳转）、CALL（调用）、RET（返回）等。
中断和异常：硬件中断触发后，PC跳转到中断向量表。
软件中断或特定的陷阱指令。

模块会实时监控来自CPU接口的虚拟程序计数器（VPC）和程序地址总线（PAB）。一旦检测到不连续，它不会记录中间所有的指令地址，而是高效地记录一对地址：跳转发生的源地址（SRC）和跳转前往的目标地址（DST）。如图13-5所示，假设一段顺序执行代码在0x50156处发生了一个跳转，跳到了0x8000（比如一个中断服务例程的入口），那么Trace Memory中就会顺序存入0x50156（SRC）和0x8000（DST）。当中断返回时，又会记录0x8016（ISR内的返回点）和0x50158（主程序恢复点）。

这种“成对记录”的方式非常节省缓冲区空间，并且保留了重建完整执行流所需的关键信息。你只需要从起始PC开始，结合反汇编代码，就能一步步“播放”出程序的执行路径。

2.2 模块架构与关键组件

PC Trace模块并非孤立工作，它与MCU内的多个子系统紧密协作，构成了一个灵活的触发与过滤体系。其功能框图（图13-6）揭示了几个关键部分：

Trace Core（追踪核心）：这是模块的大脑，负责实时监控CPU信号，判断不连续点，并将合法的地址对送入Trace Memory。它还会在每次存入新记录时产生一个“Trace Hit”事件，这个事件可以送给ERAD计数器模块，用于统计跳转次数或作为其他触发条件。
Trace Memory（追踪存储器）：这是一个固定大小的、32位宽的循环缓冲区。每个条目不仅包含22位的PC地址，还有一个至关重要的BLOCKED状态位。如果当前PC地址属于一个受DCSM（代码安全模块）保护的、当前调试会话无权访问的安全区域，那么BLOCKED位会被置1，且PROGRAM_COUNTER字段会被清零。这防止了通过调试手段泄露敏感代码。需要特别注意：这个存储器没有ECC保护，纯粹用于调试，其数据在极端噪声环境下可能出错，不能用于功能安全相关的判断。
Trace Qualifier Block（追踪限定模块）：这是PC Trace灵活性的来源。它决定了Trace在什么条件下开始、停止或生效。其输入源极其丰富，包括：
- Enhanced Bus Comparator (EBC) Units：总线比较器单元。你可以设置当地址总线、数据总线或特定总线周期匹配某个条件时，触发Trace行为。
- System Event Counter Unit：系统事件计数器。当计数器达到阈值时，可以产生事件信号。
- 直接系统事件：如PIE中断信号、ADC转换完成、PWM时基事件、GPIO输入等（详见表13-3）。这意味着你可以用“当ADC转换完成且数据大于某值”这样的复杂逻辑，来作为开始记录程序流的触发条件。
DCSM接口：提供安全区域信息，确保Trace过程不会越权。

2.3 重要限制与特性澄清

原文的Note部分包含了几个极易踩坑的关键信息，必须高度重视：

不捕获块重复（RPTB）：由RPTB（块重复）指令产生的循环，其跳转不会被PC Trace捕获。因为这在硬件层面被视为一种高效的循环机制，而非典型的程序流“不连续”。如果你的代码中有大量RPTB循环，Trace数据可能会比预期的少。
调试器访问无安全概念：调试器（如CCS）对Trace Memory的访问总是被视为非安全的。这意味着即使CPU正在安全区域执行代码，调试器也能读取Trace缓冲区（尽管BLOCKED位会置1）。这简化了调试接口的设计。
投机取指（Speculative Fetch）的影响：现代CPU为了提高性能，会进行指令预取。Trace Core会对投机取指产生的跳转也生成Hit事件，即使该指令后续并未被实际执行。这可能导致Trace缓冲区被这些“无效”的跳转记录提前填满。应对策略是：当检测到缓冲区满（BUFFER_FULL=1）时，用户可以安全地丢弃缓冲区中最旧的一对记录，因为最新的投机取指记录可能还在流水线中，而最旧的记录很可能是已确认的有效跳转。

3. PC Trace的三种工作模式详解与配置实战

PC Trace提供了三种工作模式，以适应不同的调试场景。理解它们的区别是正确配置的前提。

3.1 模式一：普通模式 (Normal Mode)

这是最直接的模式。Trace的启动和停止完全由软件通过写PCTRACE_GLOBAL.EN寄存器位来控制。

操作：写1开始记录，写0停止记录。
记录点：模块会特别记录下使能瞬间的PC值（存入PCTRACE_LOGPC_SOFTENABLE）和禁用瞬间的PC值（存入PCTRACE_LOGPC_SOFTDISABLE）。这两个地址为你划定了Trace的精确时间窗口，即使窗口的起点和终点不在一个跳转边界上。
适用场景：当你明确知道想要追踪哪一段代码（例如，从main函数开始到某个特定函数结束），并且这段代码的执行由软件流程明确控制时。配置简单，但缺乏基于运行时条件的灵活性。

3.2 模式二：窗口模式 (Windowed Trace Mode)

在此模式下，Trace的激活与否由一个外部输入信号的电平决定。

工作原理：通过PCTRACE_QUAL1.WINDOWED_INP_SEL选择一个输入信号（来自EBC、计数器或其他系统事件）。默认情况下，当该信号为高电平时，Trace激活；低电平时，Trace暂停。你可以通过WINDOWED_INP_INV位反转这个逻辑。
信号调理：对于异步信号（如来自GPIO），可以通过设置WINDOWED_INP_SYNCH位，使其经过一个两级同步器，避免亚稳态导致误触发。
适用场景：非常适合基于“条件”的追踪。例如，你想分析只有当电机电流超过某个阈值（通过ADC-EBC触发）时，控制算法的执行流是怎样的。或者，只在某个特定任务（由RTOS任务信号标识）运行时进行追踪。

3.3 模式三：启停模式 (Start-Stop Mode)

这是功能最强大的模式，使用两个独立的信号分别控制Trace的开始和停止。

工作原理：通过PCTRACE_QUAL2.START_INP_SEL和STOP_INP_SEL选择两个输入信号。Trace在START信号的上升沿（可反转）开始，在STOP信号的上升沿（可反转）停止。一旦开始，模块会忽略后续的START事件，直到收到一个STOP事件。这确保了每次追踪都是一个完整的、由事件定义的片段。
信号调理：同样，START_INP_SYNCH和STOP_INP_SYNCH位用于对应输入信号的同步。
适用场景：精确测量特定事件的执行时间或路径。经典用例就是函数或中断的性能剖析：你可以设置一个硬件断点（HWBP）在函数入口地址作为START事件，另一个HWBP在函数返回地址作为STOP事件。这样，计数器（CTM）可以测量周期数，而PC Trace则可以记录下函数内部所有的分支跳转详情，让你看到时间到底花在了哪个循环或条件判断里。

3.4 配置流程与寄存器操作要点

无论哪种模式，一个稳健的软件配置序列都遵循以下步骤。这里以普通模式为例，结合代码片段进行说明：

// 假设寄存器基地址已定义，例如 #define ERAD_BASE 0x0005F000 #define PCTRACE_GLOBAL (*(volatile uint32_t *)(ERAD_BASE + 0x100)) #define PCTRACE_QUAL1 (*(volatile uint32_t *)(ERAD_BASE + 0x104)) #define PCTRACE_BUFFER (*(volatile uint32_t *)(ERAD_BASE + 0x110)) #define PCTRACE_MEMORY_BASE (ERAD_BASE + 0x800) // Trace缓冲区起始地址 void configure_and_run_pc_trace_normal(void) { uint32_t buffer_ptr, i; uint32_t trace_entry; // 1. 初始化PC Trace模块 // 写1到PCTRACE_GLOBAL.INIT位。这会复位缓冲区指针、溢出标志，并清除LOGPC寄存器。 PCTRACE_GLOBAL = 0x00000001; // 假设INIT是bit 0 // 可选：配置模式。普通模式是上电默认，但显式设置是好习惯。 // 清除PCTRACE_QUAL1.TRACE_MODE位（假设普通模式为0） PCTRACE_QUAL1 &= ~(0x3 << 0); // 假设TRACE_MODE在bit[1:0] // 2. 启动追踪 // 在需要开始追踪的代码位置前，使能模块。 // 注意：根据手册，使能后需要插入足够的NOP，确保流水线稳定。 PCTRACE_GLOBAL |= 0x00000002; // 假设EN是bit 1 __asm(" NOP"); __asm(" NOP"); __asm(" NOP"); __asm(" NOP"); // 插入4个NOP，具体数量需参考器件数据手册对流水线深度的说明 // 3. 执行你想要剖析的代码段 my_function_to_profile(); // 你的目标函数或代码块 // 4. 停止追踪（可选，可以在运行时读取缓冲区） // 在目标代码段结束后，禁用模块。同样，禁用前需要NOP。 __asm(" NOP"); __asm(" NOP"); PCTRACE_GLOBAL &= ~(0x00000002); // 清除EN位 // 5. 读取并分析缓冲区数据 buffer_ptr = PCTRACE_BUFFER & 0xFFFF; // 假设PTR在低16位 if ((PCTRACE_BUFFER & (1<<16)) != 0) { // 假设BUFFER_FULL是bit 16 if (buffer_ptr == 0) { // 缓冲区完全满了，包含了最大数量的条目 buffer_ptr = TRACE_BUFFER_SIZE; // 使用缓冲区最大容量 } else { // 缓冲区已溢出，buffer_ptr指示溢出了多少条目（循环缓冲区） // 处理溢出逻辑，可能需要丢弃最旧的数据或标记数据不完整 } } if (buffer_ptr > 0) { // 有有效数据，成对读取 (SRC, DST) for (i = 0; i < buffer_ptr; i += 2) { // 每次循环处理一对 trace_entry = *(volatile uint32_t *)(PCTRACE_MEMORY_BASE + i*4); uint32_t pc_value = trace_entry & 0x003FFFFF; // 22位PC地址 uint8_t blocked = (trace_entry >> 22) & 0x1; // BLOCKED位 if (!blocked) { // 有效的源地址 printf("SRC: 0x%06lX -> ", pc_value); // 读取下一个条目（目标地址） trace_entry = *(volatile uint32_t *)(PCTRACE_MEMORY_BASE + (i+1)*4); pc_value = trace_entry & 0x003FFFFF; blocked = (trace_entry >> 22) & 0x1; if (!blocked) { printf("DST: 0x%06lX\n", pc_value); } else { printf("DST: BLOCKED (Security Zone)\n"); } } else { printf("SRC: BLOCKED (Security Zone)\n"); // 即使SRC被阻塞，DST条目仍然存在，但通常也无效，需要读取以移动指针 i++; // 确保索引正确前进 } } } else { printf("No trace data captured.\n"); } // 6. 读取边界地址（可选） uint32_t start_pc = PCTRACE_LOGPC_SOFTENABLE & 0x003FFFFF; uint32_t stop_pc = PCTRACE_LOGPC_SOFTDISABLE & 0x003FFFFF; printf("Trace window: 0x%06lX to 0x%06lX\n", start_pc, stop_pc); }

关键实操心得：
NOP的重要性：手册中强调在使能（EN=1）和禁用（EN=0）操作前后插入足够的NOP指令。这是因为对EN位的写操作需要几个时钟周期才能通过流水线并生效。如果紧随其后的代码本身就是跳转指令，可能会被漏记或误记。插入NOP（通常4-8条，具体看内核流水线级数）能确保流水线中是可预测的顺序代码，保证Trace开关动作的精确性。
缓冲区溢出处理：BUFFER_FULL=1且PTR>0表示发生了溢出。由于是循环缓冲区，最新的数据会覆盖最旧的数据。PTR的值指示了“新数据覆盖旧数据的起始偏移”。在分析时，你需要从PTR指示的位置开始读取，直到缓冲区末尾，然后再从缓冲区开头读到PTR-1的位置，才能获得完整的、按时间顺序的最新记录。
BLOCKED位检查：每次读取Trace条目，都必须检查BLOCKED位。如果为1，则PROGRAM_COUNTER字段为0，该记录无效。这通常发生在追踪涉及安全固件（如Bootloader）的代码流时。

4. 基于事件触发的高级配置与系统集成

窗口模式和启停模式的强大之处在于能与EBC和系统事件计数器联动。我们以一个具体的性能剖析场景为例，展示如何配置。

场景：测量电机控制中断ISR_MotorControl的执行最坏情况时间（WCET），并同时记录该中断内部分支的执行路径。

方案设计：

使用EBC（或HWBP）生成事件：
- 配置一个硬件断点（HWBP）或EBC，在ISR_MotorControl的入口地址（假设为0x9000）产生一个事件（EBC1_EVENT）。
- 配置另一个HWBP/EBC，在ISR_MotorControl的返回指令地址（0x90A0）产生一个事件（EBC2_EVENT）。
配置系统事件计数器（CTM）：
- 配置一个CTM工作在启停模式，START事件选择EBC1_EVENT，STOP事件选择EBC2_EVENT。这个CTM将自动累加从中断入口到出口的CPU周期数，其最大值就是WCET。
配置PC Trace：
- 将PC Trace也设置为启停模式，START_INP_SEL选择EBC1_EVENT，STOP_INP_SEL选择EBC2_EVENT。
- 这样，当中断触发时，Trace自动开始记录中断内部的所有跳转；中断返回时，Trace自动停止。你得到的是纯净的、仅属于该中断的完整执行流图谱。

配置代码示意：

void configure_erad_for_isr_profiling(void) { // 1. 配置EBC1 (在ISR入口地址触发) EBCH1_CONFIG = ...; // 配置为地址匹配模式，地址=0x9000，触发事件输出 EBCH1_CTRL |= EBC_ENABLE; // 2. 配置EBC2 (在ISR返回地址触发) EBCH2_CONFIG = ...; // 地址=0x90A0 EBCH2_CTRL |= EBC_ENABLE; // 3. 配置CTM1用于周期计数 CTM1_MODE = MODE_START_STOP; CTM1_START_SEL = SELECT_EBC1_EVENT; // 表13-3中的索引0 CTM1_STOP_SEL = SELECT_EBC2_EVENT; // 索引1 CTM1_CTRL |= CTM_ENABLE; // 4. 配置PC Trace PCTRACE_GLOBAL = 0x1; // INIT // 设置启停模式，假设TRACE_MODE=2 PCTRACE_QUAL1 = (2 << 0); // TRACE_MODE = Start-Stop PCTRACE_QUAL2 = (SELECT_EBC1_EVENT << 0) | (SELECT_EBC2_EVENT << 8); // START_SEL, STOP_SEL // 使能Trace（注意：在启停模式下，使能后等待START事件，而非立即开始） PCTRACE_GLOBAL |= 0x2; // EN __asm(" NOP"); __asm(" NOP"); __asm(" NOP"); __asm(" NOP"); // 5. 使能全局ERAD（如果需要） ERAD_GLOBAL_CTRL |= ERAD_ENABLE; }

当系统运行时，每次ISR_MotorControl被触发，CTM1会记录本次执行周期，PC Trace会记录内部跳转。你可以定期或在特定时刻（如系统空闲时）读取CTM1的最大值寄存器获取WCET，并导出PC Trace缓冲区进行分析。

5. 工程实践：从示例代码到实际调试

TI的C2000Ware提供了丰富的ERAD示例，是我们学习的绝佳资料。以erad_ex1_profileinterrupts.c为例，它剖析了CPU定时器中断。我们深入解读其设计思路，并扩展到自己的项目。

5.1 示例代码精读与移植要点

该示例使用了2个HWBP和4个CTM：

HWBP_1/2：标记ISR起止。
CTM_1：测量ISR执行周期（启停模式，事件同HWBP）。
CTM_2：统计定时器中断事件发生的次数（上升沿计数模式，输入为系统事件TIMER2_TINT2）。
CTM_3：统计ISR实际执行的次数（上升沿计数模式，输入为HWBP_1事件）。
CTM_4：测量从中断事件发生到ISR入口的延迟周期（启停模式，START=TIMER2_TINT2, STOP=HWBP_1）。

这个配置的精妙之处在于它进行了交叉验证和全面剖析：

CTM_2和CTM_3的差值可以告诉你因为中断关闭、优先级等原因错过了多少次中断。
CTM_4测量的是中断延迟，这对于实时系统至关重要。
CTM_1测量的是ISR本身的执行时间。

移植到自己的项目时，关键步骤如下：

定位符号地址：你需要获取目标函数或ISR的入口和出口地址。在CCS中，可以在调试时通过“Disassembly”视图查看，或者通过map文件获取。对于ISR，入口地址通常是中断向量表中指定的函数地址。
配置EBC/HWBP：使用DriverLib库函数或直接配置寄存器，设置地址匹配条件。注意，EBC可以监控数据/指令访问，而HWBP通常特指指令地址匹配。
配置CTM：根据你想测量的内容（持续时间、事件次数）选择模式（启停、边沿计数、窗口等）。
配置PC Trace：如果不仅想知道时间，还想知道执行路径，就按上述方法配置PC Trace。
编写数据读取与分析脚本：示例中使用JavaScript通过CCS的调试服务器脚本（DSS）接口自动化配置和读取。在实际项目中，你可以：
- 在线分析：在代码中定期（如在空闲任务）读取CTM和Trace缓冲区，通过串口或DAC输出。
- 离线分析：在调试会话中，通过CCS的Memory Browser和Register View手动查看，或使用更高级的脚本导出数据，用Python/Matlab进行可视化分析。

5.2 堆栈溢出检测实战

erad_ex3_stack_overflow_detect.c示例展示了另一个经典应用。其原理是配置一个EBC，监控对“栈尾之后第一个地址”的写操作。在C2000中，栈通常从高地址向低地址生长。因此，你可以将栈的结束地址（例如&__STACK_END）加上一个小的安全阈值（如4字节）作为EBC的监控地址。

一旦发生栈溢出，函数调用或局部变量就会覆盖到这个保护区，EBC立即触发一个事件。这个事件可以配置为产生一个不可屏蔽中断（NMI）或触发一个CTM计数，甚至直接连接PC Trace的STOP事件，在溢出发生时瞬间捕获最后的程序流，这对于定位导致溢出的递归调用或大局部数组至关重要。

配置核心思路：

#define STACK_END 0x0800 // 假设栈结束地址 #define GUARD_OFFSET 4 uint32_t *stack_guard_addr = (uint32_t *)(STACK_END + GUARD_OFFSET); // 配置EBC监控对该地址的写操作 EBCx_CONFIG = EBC_MODE_DATA_WRITE | EBC_ADDR_MATCH((uint32_t)stack_guard_addr); EBCx_EVENT_ACTION = EBC_ACTION_GENERATE_EVENT; // 产生事件 // 可以将此事件连接到CPU的NMI输入，或用于触发PC Trace停止并保存现场。

6. 常见问题排查与调试技巧实录

在实际使用PC Trace和ERAD时，你肯定会遇到各种问题。下面是我踩过的一些坑和总结的排查思路。

6.1 问题速查表

现象	可能原因	排查步骤与解决方案
Trace缓冲区为空（PTR=0）	1. PC Trace未使能（EN=0）。 2. 模式配置错误，触发条件未满足。 3. 代码段内无PC不连续点（全是顺序执行）。 4. 追踪的代码区域处于安全区，所有记录被BLOCKED。	1. 检查`PCTRACE_GLOBAL.EN`位。 2. 确认模式（普通/窗口/启停），检查`PCTRACE_QUAL`寄存器配置，验证触发信号是否有效（可用GPIO点灯或CTM计数辅助验证）。 3. 检查反汇编，确认目标代码段包含分支、调用等指令。 4. 检查Trace Memory中的`BLOCKED`位。尝试追踪非安全区代码验证功能。
缓冲区数据看起来混乱或地址不对	1. 使能/禁能前后未插入足够NOP。 2. 在调试模式下（CPU halted）读取数据，此时PC可能不更新。 3. 投机取指产生了无效记录。	1. 在EN位置1和置0操作前后增加更多NOP指令（尝试8条）。 2.确保在CPU全速运行时进行追踪和读取。如需读取，可在代码中暂停Trace后读取，或通过调试器在运行时读取（不暂停CPU）。 3. 结合反汇编代码分析，忽略那些在源代码中找不到对应跳转的“幽灵”记录。
启停模式无法停止	STOP事件信号未产生或未正确连接。	1. 确认STOP事件源（如EBC2）已正确配置并能使能。 2. 检查`PCTRACE_QUAL2.STOP_INP_SEL`选择是否正确。 3. 检查`STOP_INP_INV`极性设置。 4. 使用一个CTM配置为边沿计数模式，输入选择为STOP事件源，验证该事件是否确实发生。
测量周期数（CTM）与预期偏差大	1. CTM的时钟源可能不是CPU时钟（SYSCLK）。 2. 启停事件在流水线中的延迟。 3. 中断或更高优先级事件打断了被测量的代码段。	1. 检查CTM配置，确认其计数时钟源是CPU时钟。 2. 事件检测和计数器启停有最小延迟（通常几个周期），对于极短代码段测量需考虑此误差。 3. 确保测量期间禁止中断，或使用PC Trace分析是否被意外打断。
CCS脚本无法连接或配置失败	1. 工程路径或配置名变量设置错误。 2. DSS脚本执行时机不对（需在.out文件加载并运行后）。 3. 调试器连接不稳定。	1. 仔细核对`PROJ_NAME`,`PROJ_WKSPC_LOC`,`PROJ_CONFIG`变量，路径中使用双反斜杠`\\`。 2. 确保目标板已连接，程序已加载并运行（F8），然后再在Scripting Console执行`loadJSFile`。 3. 尝试重启CCS，重新连接仿真器。

6.2 独家调试技巧与心得

“由简入繁”验证法：不要一开始就配置复杂的启停模式和EBC。首先在普通模式下，追踪一个简单的、包含几个已知分支和函数调用的测试函数，验证你能正确读取到预期的地址对。这能排除硬件、基础配置和读取逻辑的问题。
利用CTM作为“逻辑分析仪”：在调试复杂的事件触发逻辑时，可以把CTM配置为“上升沿计数”模式，连接到你想监控的内部事件信号上。通过读取CTM的计数值，你可以直观地看到该事件发生了多少次，从而验证EBC、中断等是否按预期产生信号。
可视化工具是王道：原始的PC地址对列表可读性极差。一定要编写或寻找后处理脚本。一个简单的Python脚本就可以将地址对与你的.out文件或.map文件中的符号表进行匹配，生成一个带函数名的调用序列图（甚至可以用Graphviz生成图片）。这是将数据转化为洞察力的关键一步。
注意安全区的影响：如果你的项目使用了DCSM分区，并且要调试的代码涉及安全区，PC Trace的BLOCKED位会大量出现。你需要规划好调试策略，要么在非安全区复现问题，要么与安全固件团队协作，在特定调试版本中临时开放相关区域的Trace权限。
缓冲区大小管理：Trace缓冲区大小有限（查看器件手册）。对于长时间或高频率跳转的追踪，很容易溢出。在启停模式下，可以用Trace Hit事件连接一个CTM，当CTM计数（即跳转次数）接近缓冲区大小时，产生一个事件来停止Trace，从而保证捕获到的是溢出前最关键的片段。

PC Trace和整个ERAD模块是提升嵌入式系统调试深度和效率的利器。它要求开发者从更底层的硬件视角思考程序的行为。最初的配置和学习曲线可能有点陡峭，但一旦掌握，它将成为你解决最棘手实时系统问题的“终极武器”。记住，所有的配置最终都是为了回答一个问题：“我的代码到底是怎么跑的？” PC Trace给了你回答这个问题的数据。