1. 从手册到实战：理解ARM Cortex-M33调试与跟踪架构
如果你正在基于TI的CC35xx这类集成了Wi-Fi 6和蓝牙的复杂无线MCU进行开发，那么仅仅让代码跑起来是远远不够的。当系统在复杂的射频环境中出现偶发的数据丢包、时序错乱，或者某个任务莫名其妙地卡死时，传统的printf调试法往往束手无策。这时，你需要的是深入到处理器内核，像外科手术一样观察指令执行、数据流和系统状态。这就是ARM Cortex-M33内置的CoreSight调试与跟踪子系统存在的意义。它不是一堆冰冷的内存地址和比特位，而是你窥探系统运行黑盒的“内窥镜”。
手册里密密麻麻的寄存器表格，比如TRACECFG、SWIRQ、TPIU，常常让人望而生畏。但它们的本质，是ARM为开发者预留的一系列“控制开关”和“状态窗口”。通过内存映射寄存器（MMR）这种机制，你的软件可以直接与这些硬件调试模块对话。理解并配置它们，意味着你能在问题发生的瞬间抓取到最关键的现场信息，而不是在事后靠猜。对于CC35xx这类资源受限但功能复杂的无线MCU，高效的调试配置更是直接关系到产品稳定性和开发效率。接下来，我们就抛开手册式的罗列，从实际开发的角度，把这些寄存器“用活”。
2. 调试子系统核心：HOST_MCU寄存器组深度解析
手册中HOST_MCU寄存器组位于一个特定的内存映射区域，它是芯片设计商（这里是TI）为Cortex-M33的调试与跟踪功能提供的“总控台”。这个寄存器组并不属于标准的ARM CoreSight组件，而是芯片厂商实现的“胶合逻辑”，用于管理调试子系统与芯片其他部分（如总线、时钟、安全域）的交互。理解这些寄存器，是让标准CoreSight组件在特定芯片上正确工作的前提。
2.1 跟踪时钟配置：TRACECFG寄存器
TRACECFG寄存器是调试跟踪功能的“心跳”发生器。跟踪端口（如TPIU）输出数据需要一个时钟，这个时钟通常由系统主频分频而来，以确保与外部调试器（如JTAG/SWD适配器）的时钟速率匹配。
寄存器字段精讲：
- CLKDIVVAL (Bits [1:0]): 时钟分频值配置。这是核心。
0h: 二分频。假设输入时钟tpiu_trace_clk_in为40MHz，则输出跟踪时钟为20MHz。1h: 四分频（默认值）。输入时钟40MHz时，输出为10MHz；输入20MHz时，输出为5MHz。2h和3h: 手册明确标注不支持，切勿使用。
- CLKDIVEN (Bit 8): 分频使能位。这是一个关键的操作顺序陷阱！你必须先配置好
CLKDIVVAL，然后再将CLKDIVEN写1，新的分频值才会生效。直接写CLKDIVVAL是不会立即改变输出时钟的。
配置实战与考量：假设你的系统主频为80MHz，提供给TPIU的输入时钟是40MHz，而你使用的调试器最高支持10MHz的跟踪时钟速率。你的配置步骤应该是：
- 确定分频比：需要从40MHz得到10MHz，分频比为4，对应
CLKDIVVAL = 1h。 - 编写配置代码。注意，对这类控制寄存器的访问通常需要确保是32位对齐的原子操作，并且要考虑寄存器所在的内存区域是否允许非对齐访问（通常不允许）。
// 假设 HOST_MCU_REG_BASE 是 HOST_MCU 寄存器组的基地址 #define TRACECFG_REG (*(volatile uint32_t *)(HOST_MCU_REG_BASE + 0x00)) void configure_trace_clock(void) { uint32_t reg_val; // 1. 读取当前寄存器值，避免修改保留位 reg_val = TRACECFG_REG; // 2. 清除 CLKDIVVAL 字段 reg_val &= ~(0x00000003UL); // 3. 设置四分频 (CLKDIVVAL = 1) reg_val |= (1UL << 0); // 4. 清除并设置 CLKDIVEN 位（先确保关闭，再在写入分频值后开启） reg_val &= ~(1UL << 8); // 先暂时禁用 TRACECFG_REG = reg_val; // 写入分频值，但分频器未生效 // 5. 使能分频器 reg_val |= (1UL << 8); TRACECFG_REG = reg_val; // 此时，新的10MHz跟踪时钟才生效 }注意：在实际操作中，你还需要查阅芯片数据手册，确认
tpiu_trace_clk_in的准确来源和频率。有些芯片可能需要额外配置时钟树，才能给TPIU提供时钟。
2.2 跨安全域与核间调试：SWIRQ、NSSWIRQ、SWIRQCM3
在Cortex-M33这类支持TrustZone安全扩展的MCU中，软件通常运行在安全（Secure）和非安全（Non-Secure）两个世界。SWIRQ、NSSWIRQ和SWIRQCM3这组寄存器，提供了通过软件触发中断来进行跨域或跨核调试通信的能力。
- SWIRQ (Software Timestamp Interrupt): 这个寄存器的主要功能是写入时间戳。当调试工具或软件在ETM（嵌入式跟踪宏单元）或系统事件跟踪（ETB）总线上插入一个时间戳事件时，可以向这个寄存器的
TIMESTAMP字段写入一个值。这个值会被跟踪硬件捕获，并与当时的跟踪数据流关联，用于后续在调试器中精确还原事件发生的时间线。它本身不直接产生中断到CPU。 - NSSWIRQ (Non-Secure Software Interrupt): 这是非安全世界向安全世界发起调试通信的关键。当非安全世界的软件（例如，用户应用程序）需要主动通知安全世界（例如，安全服务或监控程序）时，可以向该寄存器的
EN字段写1。这会触发一个中断到安全世界的处理器上下文。这在调试混合安全属性的复杂系统时非常有用，例如，非安全应用可以主动请求安全服务执行某个诊断操作。 - SWIRQCM3 (Software Interrupt to CM3): 在CC35xx这类多核系统中（可能包含Cortex-M33和一个Cortex-M3协处理器），这个寄存器允许M33的非安全世界去中断M3核心。这用于核间调试协调，比如让M33控制M3的调试状态机，或者同步两个核心的断点操作。
实操心得：在调试涉及TrustZone的崩溃问题时，如果安全世界的故障导致非安全世界挂起，你可以预先在非安全世界的关键代码段设置“心跳”机制。通过定期写NSSWIRQ寄存器，安全世界的监控中断服务程序（ISR）可以确认非安全世界仍在运行。一旦心跳停止，安全世界可以触发安全诊断或恢复流程。这比等待看门狗超时更精确。
2.3 调试总线仲裁策略：ARBPOL寄存器
在有多主设备（如Cortex-M33的D-Code总线、S-Code总线、系统总线，以及可能的DMA控制器）争用调试子系统（如ETM、TPIU）的访问接口时，仲裁策略决定了谁优先。ARBPOL寄存器控制着访问存储器子系统（MEMSS）前两个仲裁器的策略。
字段解析：
- RNDRBNS0 (Bit 0): 控制MEMSS Portion A（端口A）前仲裁器的策略。
0: 固定优先级（Fixed Priority）1: 轮询优先级（Round Robin）（默认）
- RNDRBNS1 (Bit 1): 控制MEMSS Portion B（端口B）前仲裁器的策略。
0: 固定优先级1: 轮询优先级（默认）
- S0PRIM0 (Bits [3:2]) 和 S0PRIM1 (Bits [5:4]): 当端口A的仲裁器设为固定优先级时，这两个字段分别用于配置
udma/sahb和ocp主设备的优先级。数值越高，优先级通常越高（需查具体手册确认编码）。 - S1PRIM0 (Bits [7:6]) 和 S1PRIM1 (Bits [9:8]): 功能同上，但针对端口B的仲裁器。
配置策略选择：
- 轮询优先级：公平性更好，能防止低优先级主设备被完全“饿死”。适用于调试流量和DMA传输都较为频繁，且没有绝对实时性要求的场景。
- 固定优先级：可预测性更强。你可以将调试访问（例如通过
ocp接口）设置为最高优先级，确保即使在总线拥堵时，调试器的读写命令也能被快速响应，这对于单步调试、实时查看变量的体验至关重要。但需小心，这可能会阻塞DMA对关键数据（如音频流、射频数据包）的传输。
配置示例：假设为了获得最灵敏的调试体验，我们决定将调试访问优先级设为最高。
#define ARBPOL_REG (*(volatile uint32_t *)(HOST_MCU_REG_BASE + 0x24)) void set_debug_priority_highest(void) { uint32_t reg_val = ARBPOL_REG; // 1. 将两个仲裁器都设置为固定优先级模式 reg_val &= ~(1UL << 0); // 清除 RNDRBNS0，设为固定优先级 reg_val &= ~(1UL << 1); // 清除 RNDRBNS1，设为固定优先级 // 2. 配置端口A仲裁器：假设 ocp (S0PRIM1) 为调试主设备，设其优先级为最高（例如3） reg_val &= ~(0x3UL << 4); // 先清零 S0PRIM1 reg_val |= (0x3UL << 4); // 设置为3（假设3为最高） // 3. 配置端口B仲裁器：同理 reg_val &= ~(0x3UL << 8); // 清零 S1PRIM1 reg_val |= (0x3UL << 8); // 设置为最高优先级 ARBPOL_REG = reg_val; }2.4 调试子系统锁机制：DBGSS、DBGSSLCK、DBGSSLM、DBGSSLS
这是一组用于管理调试子系统访问权限和电源状态的寄存器，在多任务或低功耗场景下尤为重要。
- DBGSS (Debug Subsystem Control): 其
EN位用于使能或禁用整个调试子系统。在某些低功耗模式下，为了彻底切断调试模块的功耗，可以先通过此寄存器禁用调试子系统。注意：禁用后，调试器将失去连接，必须通过芯片复位或特定唤醒事件来恢复。 - DBGSSLCK (Debug Interface Lock): 这是一个软件锁。当多个软件线程或一个软件与一个调试器可能同时访问调试资源时，需要此锁来防止冲突。其操作方式很独特：
- 读操作：尝试获取锁。读回
1表示成功获取（读操作期间无调试请求）；读回0表示获取失败（有调试请求活跃），需要重试。 - 写
1：强制获取锁（无视调试请求状态）。 - 写
0：释放锁。
- 读操作：尝试获取锁。读回
- DBGSSLM (Lock Condition Mask):
MASK位。当设置为1时，在通过DBGSSLCK读操作检查锁条件时，会屏蔽掉“调试主机强制激活”(FRCACT)这个条件。这意味着即使调试器在强制保持调试接口活跃，软件也可能成功获取锁。这给了软件更高的控制权，但使用不当可能导致调试器通信异常。 - DBGSSLS (Lock Condition Status): 状态寄存器。
FRCACT: 指示调试主机（如JTAG调试器）是否正在强制保持调试接口处于活动状态。这对于实现“调试器连接感知”的软件逻辑很有用。CSYSPWRREQ: 指示调试主机是否正在请求系统时钟保持运行。在深度睡眠模式下，如果此位为1，软件应避免关闭系统时钟，否则会断开调试连接。
避坑指南：在编写低功耗管理代码时，一个常见的错误是：软件准备进入深度睡眠，它检查DBGSSLS寄存器，发现FRCACT=0且CSYSPWRREQ=0，于是认为没有调试器连接，便放心地关闭了调试模块的时钟甚至电源。然而，就在关闭的瞬间，调试器可能刚刚上电并尝试连接，这会导致芯片“睡死”，无法再被调试器唤醒。更稳健的做法是：
- 在允许进入最深低功耗模式前，不仅检查状态位，还可以通过
DBGSSLCK尝试获取锁。如果多次尝试失败（说明有持续的调试访问），则主动放弃进入该模式，或进入一个能保持调试接口供电的稍浅的睡眠模式。 - 提供一个明确的软件接口（如一个特定的GPIO状态或串口命令），让生产或测试人员可以告知固件“允许进入无调试支持的深度睡眠”。
3. 安全世界调试接口：HOST_MCU_SEC寄存器组简析
这个寄存器组是安全世界专属的调试控制接口，与非安全世界的HOST_MCU组对应。
- SSWIRQ2NS: 安全世界软件中断到非安全世界。这是
NSSWIRQ的反向通道。安全世界的可信代码可以通过写此寄存器来中断非安全世界，例如传递安全事件通知或触发非安全世界的调试回调。 - SWIRQ2CM3: 安全世界到CM3核心的软件中断。功能同
SWIRQCM3，但发起方是安全世界。 - LCKUP: 锁存状态寄存器。这是一个只读状态位，当处理器因不可恢复的错误（如硬Fault中再发生硬Fault）而进入“锁死”状态时，此位会被置1。软件可以轮询此位（通常在一个高优先级的定时器或监控任务中）来检测系统是否已锁死，并触发全局复位或安全恢复流程。注意：一旦进入锁死状态，CPU停止执行指令，只有复位、更高优先级异常（如NMI）或调试器介入才能退出。因此，轮询此位的代码必须能在锁死前运行。
4. CoreSight组件发现：CPU_ROM_TABLE寄存器组
这是ARM CoreSight架构的精妙设计之一——自发现机制。调试工具（如Keil MDK、IAR或OpenOCD）在上电连接后，并不知道芯片内部有哪些调试组件（DWT, ITM, TPIU, ETM等）以及它们位于什么地址。CPU_ROM_TABLE就是一个只读的、固定格式的索引表，位于一个众所周知的地址（对于Cortex-M系列，通常是0xE00FF000），它像一本书的目录一样，列出了所有可用的调试组件及其基地址。
4.1 ROM表条目解析：以SCS_ENTRY为例
我们以第一个条目SCS_ENTRY（系统控制空间）为例，拆解其信息：
- BASE_ADDR (Bits [31:12]): 这是组件基地址的高20位。例如，复位值
0x000FFF0F表示基地址为0xE000E000（因为对于CoreSight，基地址通常是0xE0000000 | (BASE_ADDR << 12)，但具体计算需参考架构手册）。这正是Cortex-M系统控制块（SCB）和SysTick等寄存器的标准地址。 - ENTRY_PRESENT (Bit 0): 这是最关键的一位。
1表示该条目有效，对应的调试组件存在。0则表示该组件在芯片中未实现。例如，在提供的资料中，TPIU_ENTRY、ETM_ENTRY、CTI_ENTRY、MTB_ENTRY的ENTRY_PRESENT位都是0，说明这款具体的CC35xx芯片可能没有实现这些高级跟踪组件，或者它们被永久禁用。 - FORMAT (Bit 1): 指示条目格式。通常为1，表示这是标准的32位偏移格式。
- POWER_DOMAIN_ID_VALID (Bit 2) & POWER_DOMAIN_ID (Bits [8:4]): 与电源管理相关，指示该组件属于哪个电源域。这对于在多电源域芯片上管理调试模块的功耗很重要。
4.2 组件ID与设计者识别：PIDRx与CIDRx寄存器
ROM_TABLE末尾的PIDR0-PIDR7和CIDR0-CIDR3寄存器用于识别组件。
- PIDR (Peripheral ID): 外设标识符。它告诉工具“这是什么组件”。例如，
PIDR0和PIDR1中的PART_0和PART_1字段共同组成一个12位的部件号。PIDR1.DES_0、PIDR2.DES_1、PIDR4.DES_2共同标识了设计者（如ARM）。PIDR2.REVISION指示硅片修订版本（如r1p0）。PIDR2.JEDEC位为1表示使用JEDEC分配的设计者ID。 - CIDR (Component ID): 组件标识符。它告诉工具“这是哪一类CoreSight组件”。
CIDR0-CIDR3中的PRMBL_0到PRMBL_3组成一个32位的魔数，对于ROM表，这个值通常是0x5BA00477（0xB1, 0x05, 0x00, 0x0D的组合需要看具体字节序）。CIDR1.CLASS字段指示组件类别，例如1可能表示这是一个ROM表。
调试工具如何工作：
- 工具连接到芯片，通过SWD/JTAG读取
ROM_TABLE起始地址。 - 从偏移
0x0开始，依次读取每个条目（如SCS_ENTRY,DWT_ENTRY...）。 - 检查
ENTRY_PRESENT位。如果为1，则根据BASE_ADDR计算出该调试组件的完整基地址。 - 工具跳转到该基地址，并读取该组件自己的
PIDR/CIDR寄存器进行二次验证。 - 工具据此构建出芯片内完整的调试组件拓扑图，并允许你配置和使用它们（如设置DWT数据观察点、使能ITM软件跟踪等）。
实操要点：如果你的自定义调试工具或脚本无法自动发现组件，可以手动遍历这个ROM表。例如，在内存查看器中查看地址0xE00FF000，你会看到一系列32位数值，解析它们就能知道芯片提供了哪些调试资源。这对于在裸机环境或非标准IDE下进行底层调试至关重要。
5. 跟踪端口接口单元：TPIU寄存器配置实战
TPIU是CoreSight跟踪架构的“出口”。它将芯片内部并行的跟踪数据流（来自ITM、DWT、ETM）序列化，并通过少量的引脚（SWO引脚）发送给外部调试探头。配置TPIU是使用SWO跟踪功能的核心。
5.1 端口协议与时钟配置：SPPR、ACPR、CSPSR
这是建立物理通信链路的三部曲。
SPPR (Selected Pin Protocol) - 选择输出协议：
0x00: TracePort模式。需要多个数据引脚，提供最高带宽，但占用引脚多，在小型封装MCU上不常见。0x01:串行线输出（Manchester编码）。这是默认值。曼彻斯特编码自带时钟信息，抗干扰性好，但对探头要求稍高。0x02:串行线输出（NRZ编码）。不归零编码，更常见，需要单独的时钟线（SWCLK）来采样数据。选择建议：对于CC35xx和大多数现代调试器，NRZ模式（0x02）是兼容性最好的选择。务必在跟踪数据流停止时更改此配置，否则会导致数据损坏。
ACPR (Async Clock Prescaler) - 设置波特率： 此寄存器用于在异步串行模式（NRZ或Manchester）下分频TPIU输入时钟，以产生所需的SWO波特率。
- 公式：
SWO_BaudRate = tpiu_trace_clk_in / (PRESCALER + 1) - 例如：输入时钟
tpiu_trace_clk_in = 40MHz，目标SWO波特率为2Mbps。 计算：PRESCALER = 40,000,000 / 2,000,000 - 1 = 20 - 1 = 19 (0x13)。关键点：波特率受限于输入时钟和分频器精度。过高的波特率可能导致数据错误，过低则可能丢数据。通常选择调试器支持的通用波特率，如1Mbps, 2Mbps, 4Mbps。
- 公式：
CSPSR (Current Sync Port Size) - 设置端口宽度： 在同步模式（TracePort）下使用。对于SWO（单线输出），此寄存器应保持为
1（1-bit端口）。在配置前，应先读取SSPSR（Supported Sync Port Sizes）了解硬件支持的能力。绝对不要设置SSPSR不支持的位，也不要同时设置多位。
完整的TPIU初始化代码示例：
// 假设 TPIU_BASE 地址已通过 ROM_TABLE 发现获得，例如 0xE0040000 #define TPIU_SPPR (*(volatile uint32_t *)(TPIU_BASE + 0x0F0)) #define TPIU_ACPR (*(volatile uint32_t *)(TPIU_BASE + 0x010)) #define TPIU_CSPSR (*(volatile uint32_t *)(TPIU_BASE + 0x004)) #define TPIU_FFCR (*(volatile uint32_t *)(TPIU_BASE + 0x304)) void tpiu_init_for_swo(uint32_t trace_clk_hz, uint32_t swo_baudrate) { uint32_t prescaler; // 1. 确保跟踪数据流已停止（例如，通过停止内核或确认无跟踪源激活） // 2. 选择NRZ协议 (0x02) TPIU_SPPR = 0x00000002; // 3. 计算并设置异步时钟分频器 if ((trace_clk_hz == 0) || (swo_baudrate == 0) || (trace_clk_hz < swo_baudrate)) { // 错误处理：使用一个安全的默认值，例如 1Mbps 分频 prescaler = (trace_clk_hz / 1000000) - 1; } else { prescaler = (trace_clk_hz / swo_baudrate) - 1; } // 确保 prescaler 能放入13位字段 (0-8191) if (prescaler > 0x1FFF) { prescaler = 0x1FFF; } TPIU_ACPR = prescaler & 0x1FFF; // 4. 设置端口大小为1-bit (对于SWO) TPIU_CSPSR = 0x00000001; // 5. （可选）配置格式化器与刷新控制寄存器 // 使能连续格式化，并允许插入触发包 TPIU_FFCR = (1 << 8) | (1 << 1); // TRIGIN=1, ENFCONT=1 }5.2 数据格式化与同步：FFCR与PSCR寄存器
TPIU输出的数据流不是原始数据，而是被打包成带有帧头、数据负载和校验的“数据包”。FFCR和PSCR寄存器控制这个过程。
- FFCR (Formatter and Flush Control):
ENFCONT位：使能连续格式化。必须置1，否则TPIU不会持续输出数据包。TRIGIN位：使能外部触发输入。当调试探头的TRIGIN信号有效时，TPIU会在数据流中插入一个特殊的触发包。这在同步多个跟踪流或标记特定事件时非常有用。
- PSCR (Periodic Synchronization Counter):
PSCOUNT字段：设置周期性同步包插入的间隔。同步包用于帮助调试器在数据流丢失或错位时重新对齐。- 例如，设置为
0b01000（十进制8）表示每256字节插入一个同步包。在数据率很高或链路可能受干扰时，可以设置较短的间隔（如128字节）。如果追求最大有效数据带宽，可以禁用它（设为0），但风险是如果发生字节错位，可能导致大量后续数据解析失败。
配置建议：对于大多数应用，使能ENFCONT和TRIGIN，并将PSCR设置为一个适中的值（如256或512字节）是一个良好的起点。
5.3 声明标签与设备ID：CLAIMTAG与DEVID
- 声明标签寄存器组 (
CLAIMMASK,CLAIMSET,CLAIMTAG,CLAIMCLR)：这套寄存器主要用于多核调试或当多个调试代理（如一个JTAG调试器和一个自检软件）需要共享TPIU资源时，实现简单的“锁”机制。一个代理通过写CLAIMSET来“声明”自己需要使用TPIU，用完后通过写CLAIMCLR释放。在实际的单调试器场景中，通常不需要手动操作。 - DEVID (Device ID)：这是一个简单的只读寄存器，用于查询TPIU是否连接了ETM。读回
0xCA1表示有ETM，0xCA0表示没有。这可以用于软件自动检测可用的跟踪能力。
6. 常见调试问题排查与实战技巧
即使按照手册配置了所有寄存器，跟踪功能仍然可能无法工作。以下是一些常见问题及排查思路。
6.1 问题1：SWO引脚无输出
- 检查清单：
- 引脚复用：这是最常见的原因！SWO信号（通常是
SWO或TDO引脚）可能与其他功能（如GPIO、UART）复用。你必须查阅CC35xx的数据手册（Datasheet）或引脚复用表，确保在系统初始化早期，就将该引脚配置为跟踪输出功能，而不是普通的GPIO。 - 时钟未使能：确认提供给TPIU的源时钟（
tpiu_trace_clk_in）已由芯片的时钟控制系统使能。它可能来自系统主时钟的分频，需要配置相应的时钟门控或分频器寄存器。 - TPIU未使能：在某些芯片中，TPIU模块本身可能有一个独立的使能位（可能位于系统控制寄存器或电源管理寄存器中），需要被打开。
- 协议与波特率不匹配：确认
SPPR寄存器设置的协议（NRZ）与调试器软件中的设置完全一致。确认ACPR计算出的波特率在调试器支持的范围内，且与调试器配置的波特率匹配。一个技巧：先将波特率设得很低（如9600），看是否有任何数据输出，再逐步提高。 - 跟踪源未激活：TPIU只是一个“管道”。你必须同时使能数据源，例如：
- 在ITM寄存器中使能激励端口（Stimulus Ports）并为其分配通道。
- 在DWT寄存器中使能PC采样、数据地址采样等跟踪事件。
- 在CoreSight控制寄存器中使能跟踪单元。
- 引脚复用：这是最常见的原因！SWO信号（通常是
6.2 问题2：调试器可以连接但无法识别跟踪组件
- 检查清单：
- ROM表读取失败：调试器第一步就是读ROM表。检查芯片的调试访问端口（DAP）是否已解锁。有些芯片在安全启动后或处于某些低功耗模式时，会锁定调试接口。
- 电源域关闭：如果
CPU_ROM_TABLE条目中的POWER_DOMAIN_ID_VALID为1，且对应的电源域被关闭，那么该调试组件将不可访问。确保所有涉及调试子系统的电源域都已上电。 - 芯片特定锁：回顾
DBGSSLCK和DBGSSLM寄存器。是否有其他软件（如安全固件）持有了调试锁？调试器的强制激活(FRCACT)是否被屏蔽(MASK=1)？
6.3 问题3：跟踪数据不完整或错乱
- 检查清单：
- 波特率过高：这是导致数据错乱的首要原因。降低
ACPR的分频值，使用更低的SWO波特率。线缆过长或质量不佳也会限制最高可靠波特率。 - 缓冲区溢出：TPIU或ITM的FIFO缓冲区可能太小，而数据产生速率太快。尝试减少跟踪的数据量，例如，关闭不必要ITM通道，降低DWT的采样频率。
- 缺少同步包：如果
PSCR被禁用（PSCOUNT=0），且链路受到干扰，一旦发生一位错误，后续所有数据都可能无法解析。尝试启用周期性同步（如设置PSCOUNT=8）。 - 软件冲突：如果软件也在频繁访问调试寄存器（例如，通过DWT进行性能计数），可能会与调试器的访问冲突。确保软件在调试会话期间避免操作关键的调试控制寄存器。
- 波特率过高：这是导致数据错乱的首要原因。降低
6.4 高级技巧：利用DWT和ITM进行非侵入式调试
当SWO配置好后，你可以超越简单的断点，进行更强大的调试：
- DWT数据观察点：配置DWT比较器寄存器，让CPU在特定变量被读写（甚至达到特定次数）时，通过ITM发送一个数据包到SWO输出。这样你可以在不停止CPU的情况下，监控关键变量的变化历史。
- ITM软件插桩：在你的代码中插入
ITM_SendChar()之类的函数调用，将调试信息（如函数入口、变量值、状态码）通过指定的ITM通道发送出去。这比UART打印更高效，且时间戳精确。 - DWT周期计数：使能DWT的周期计数器(
CYCCNT)，并结合ITM输出，可以测量代码段的精确执行周期数，进行性能剖析。
配置这些功能需要访问DWT和ITM的寄存器，它们的基地址可以通过CPU_ROM_TABLE中的DWT_ENTRY和ITM_ENTRY找到（如果ENTRY_PRESENT为1）。这为你打开了一扇通往高性能、实时系统调试的大门。
