企业官网建设流程全解析

1. 项目概述与调试跟踪的价值

在嵌入式开发这个行当里，调试和跟踪功能就像是给系统装上了“X光机”和“黑匣子”。没有它们，面对一个运行在几十兆赫兹、内存以KB计、且一旦部署就难以直接接触的微控制器，排查一个偶发的死机或者性能瓶颈，无异于大海捞针。特别是对于像德州仪器CC35xx这类集成了复杂无线协议栈（Wi-Fi 6 & Bluetooth LE）的SoC，其内部多核（如Cortex-M33与Cortex-M3协同）、多安全域（安全与非安全世界）的架构，使得传统的“点个灯、打个串口”的调试手段完全不够用。这时，深入理解并熟练配置处理器内核自带的调试与跟踪子系统，就成了资深工程师的必备技能。

ARM Cortex-M33作为ARMv8-M架构的主力，其调试与跟踪架构基于成熟的CoreSight技术，提供了从程序流跟踪、数据监视到系统性能分析的一整套非侵入式方案。我们手头这份CC35xx的技术手册片段，恰好揭示了芯片厂商如何在其SoC中具体实现并扩展这些CoreSight组件。它不仅仅是寄存器列表，更是一张通往芯片内部观测世界的“地图”。通过配置HOST_MCU寄存器组，我们可以管理芯片级的调试接口、跨核/跨安全域的中断，以及跟踪端口的时钟；而TPIU（Trace Port Interface Unit）寄存器的配置，则直接决定了跟踪数据如何以何种格式、何种速率从芯片引脚输出，被外部的调试探针（如J-Link， DAPLink）捕获和分析。

掌握这些寄存器的配置，意味着你能在代码疯狂跑飞时，不是盲目地添加打印语句（这在实时系统中往往是灾难），而是能精准地设置硬件断点、观察点，甚至实时捕获函数调用序列和关键变量的变化历史。这对于开发高可靠的物联网设备、汽车电控单元或工业控制器至关重要。接下来，我们就抛开枯燥的文档描述，以一线开发者的视角，拆解这些关键寄存器，并分享从实际项目中总结出的配置要点和避坑指南。

2. HOST_MCU寄存器组深度解析与实战配置

HOST_MCU寄存器组是芯片厂商（这里是TI）为管理片上调试与跟踪资源而设计的一组控制寄存器。它们通常映射到处理器的系统总线地址空间，通过内存访问指令（如LDR/STR）进行配置。理解这组寄存器，是打通从应用代码到底层调试硬件通道的第一步。

2.1 跟踪时钟配置（TRACECFG）

TRACECFG寄存器位于偏移0x0，是配置跟踪端口接口单元（TPIU）输入时钟的关键。跟踪数据的输出速率和稳定性直接受此时钟影响。

寄存器字段精讲：

• CLKDIVVAL (Bits [1:0]): 跟踪时钟分频值。这是一个R/W（可读可写）字段，但它的生效有特殊顺序。
  • 0b00: 分频比 1（即不分频）。注意：手册注明[0]不支持，此处0b00对应“Divide by 2”？这里需要结合上下文和典型值判断。通常，0b00可能代表“Divide by 1”或保留，而手册描述[1] - Divide by 2，[2] - Divide by 4。我们以手册表格描述为准：0h = Divide by 2,1h = Divide by 4。[0,3]不支持。因此，有效值只有0（二分频）和1（四分频）。假设输入时钟tpiu_trace_clk_in为80MHz，那么选择0得到40MHz跟踪时钟，选择1得到20MHz。
• CLKDIVEN (Bit 8): 时钟分频使能位。这是一个W（只写）位，用于锁存CLKDIVVAL的值。这是最关键的实操步骤：你必须先配置好CLKDIVVAL，然后再向CLKDIVEN位写入1，新的分频值才会生效。直接写CLKDIVVAL是不会立即改变时钟的。

配置流程与代码示例：假设我们需要将跟踪时钟配置为20MHz（输入时钟80MHz，四分频）。

// 定义寄存器地址（基地址需查阅芯片内存映射表，此处假设为0x4000_0000） #define HOST_MCU_BASE (0x40000000U) #define TRACECFG_OFFSET (0x0U) #define TRACECFG_REG (*(volatile uint32_t *)(HOST_MCU_BASE + TRACECFG_OFFSET)) void configure_trace_clock(void) { uint32_t reg_val; // 1. 读取当前寄存器值，避免修改保留位 reg_val = TRACECFG_REG; // 2. 清除并设置CLKDIVVAL字段为1（四分频） reg_val &= ~(0x00000003U); // 清除bit[1:0] reg_val |= (1U << 0); // 设置CLKDIVVAL = 1 (Divide by 4) // 3. 将新值写回寄存器，此时CLKDIVEN=0，分频未生效 TRACECFG_REG = reg_val; // 4. 关键步骤：设置CLKDIVEN位为1，激活新的分频值 // 注意：CLKDIVEN是只写位，我们通过再次写入整个寄存器来设置它，但必须保持CLKDIVVAL不变。 // 更安全的做法是直接写入一个同时设置CLKDIVEN和CLKDIVVAL的值。 TRACECFG_REG = (1U << 8) | (1U << 0); // CLKDIVEN=1, CLKDIVVAL=1 // 或者，如果硬件允许，可以先写CLKDIVVAL，再单独写一个操作置位CLKDIVEN。 // 但根据描述“Set this register to load [CLKDIVVAL]”，通常是一次配置。 }

实操心得：很多工程师在这里栽跟头，配置了分频值却发现时钟没变，根本原因就是漏掉了使能锁存这一步。务必记住“先配值，后使能”的顺序。另外，跟踪时钟频率需与后端调试探针的捕获能力匹配，过高的频率可能导致数据丢失。

2.2 软件中断与时间戳（SWIRQ， NSSWIRQ， SWIRQCM3）

这组寄存器用于在芯片内部不同处理单元（Cortex-M33的安全/非安全世界、Cortex-M3核心）之间触发软件中断，以及为嵌入式跟踪（ETM）总线插入时间戳。

• SWIRQ (Offset 0x18): 软件时间戳中断寄存器。其低16位TIMESTAMP是一个可读写的字段，用于向ETM总线写入时间戳值。当ETM配置为捕获时间戳包时，向此寄存器写入值会生成一个特定的事件包，有助于在跟踪流中标记关键事件的发生时刻，便于后续在调试工具中按时间对齐多条跟踪流。
• NSSWIRQ (Offset 0x1C): 非安全软件中断寄存器。Cortex-M33的非安全上下文可以通过写此寄存器的EN字段（低4位）来中断安全上下文。这是ARM TrustZone技术中，非安全世界调用安全服务的一种底层通信机制。
• SWIRQCM3 (Offset 0x20): 到CM3的软件中断寄存器。Cortex-M33（可能是其非安全或安全上下文，根据手册描述为Non Secure context）可以通过写此寄存器的EN位（bit 0）来中断另一个Cortex-M3核心。这在多核调试或核间通信同步时非常有用。

应用场景与配置注意：

// 触发一个从M33非安全世界到M3核心的软件中断 #define NSSWIRQ_REG (*(volatile uint32_t *)(HOST_MCU_BASE + 0x1CU)) #define SWIRQCM3_REG (*(volatile uint32_t *)(HOST_MCU_BASE + 0x20U)) void trigger_interrupt_to_m3(void) { // 确保当前处于非安全状态（通常由SAU或IDAU配置决定） // 向SWIRQCM3的EN位写1，产生中断 SWIRQCM3_REG = 0x00000001U; // 中断触发后，该位可能由硬件自动清除，或需要软件清除，需查阅更详细的中断控制器手册。 } // 在ETM跟踪流中插入一个时间戳 void insert_timestamp(uint16_t ts_value) { volatile uint32_t *swirq_reg = (volatile uint32_t *)(HOST_MCU_BASE + 0x18U); *swirq_reg = (uint32_t)ts_value; // 写入时间戳值 }

注意事项：使用跨安全域或跨核中断时，必须事先配置好目标核心的中断控制器（如NVIC），使能对应的中断通道，并设置好优先级。否则，中断可能无法被响应。时间戳的写入时机需要结合ETM的配置，确保ETM已使能并配置为捕获时间戳包。

2.3 仲裁策略配置（ARBPOL）

ARBPOL寄存器（偏移0x24）用于配置访问芯片内部存储器子系统（MEMSS）之前两个仲裁器（Arbiter）的优先级策略。这在多主设备（如Cortex-M33, DMA, 其他总线主机）竞争访问内存时，决定了谁先谁后，直接影响系统的实时性和性能。

字段详解：

• RNDRBNS0 (Bit 0): 仲裁器0（MEMSS Portion A前）策略选择。0=固定优先级，1=轮询优先级（默认）。
• RNDRBNS1 (Bit 1): 仲裁器1（MEMSS Portion B前）策略选择。0=固定优先级，1=轮询优先级（默认）。
• S0PRIM0 (Bits [3:2]): 当仲裁器0为固定优先级时，用于配置udma/sahb主设备的优先级。
• S0PRIM1 (Bits [5:4]): 当仲裁器0为固定优先级时，用于配置ocp主设备的优先级。
• S1PRIM0 (Bits [7:6]): 当仲裁器1为固定优先级时，用于配置udma/sahb主设备的优先级。
• S1PRIM1 (Bits [9:8]): 当仲裁器1为固定优先级时，用于配置ocp主设备的优先级。

策略选择与性能考量：

• 轮询优先级：每个主设备轮流获得访问权，公平性好，能防止低优先级主设备被“饿死”。适用于多个活跃度相当的主设备场景。
• 固定优先级：高优先级主设备总能优先访问。适用于有严格实时性要求的主设备（如实时控制核、高速DMA）。你需要明确每个主设备的业务关键性。

配置示例：假设我们需要确保Cortex-M33对某个内存区域的访问具有最低延迟，而DMA（假设通过udma/sahb访问）可以容忍一定延迟。

#define ARBPOL_REG (*(volatile uint32_t *)(HOST_MCU_BASE + 0x24U)) void configure_arbiter_for_low_latency_cpu(void) { uint32_t reg_val = 0; // 我们只配置仲裁器0（Portion A）为例 // 1. 设置仲裁器0为固定优先级模式 reg_val &= ~(1U << 0); // 清除RNDRBNS0，设为固定优先级 // 2. 在固定优先级下，设置优先级。假设优先级值越大，优先级越高。 // 配置ocp（可能代表CPU）优先级为最高（3）， udma/sahb优先级为低（0） reg_val &= ~(0x3U << 4); // 清除S0PRIM1 reg_val |= (3U << 4); // 设置S0PRIM1 = 3 (ocp high priority) reg_val &= ~(0x3U << 2); // 清除S0PRIM0 reg_val |= (0U << 2); // 设置S0PRIM0 = 0 (udma/sahb low priority) ARBPOL_REG = reg_val; }

踩坑记录：盲目使用固定优先级可能导致低优先级主设备（如后台数据搬运的DMA）长期无法访问内存，从而引发缓冲区溢出或系统卡顿。在调整仲裁策略后，务必对系统进行高负载测试，观察是否所有主设备都能在预期时间内完成访问。一个常见的调试方法是利用性能监控单元（如果可用）或通过GPIO翻转来测量各主设备的访问延迟。

2.4 调试子系统控制与锁定（DBGSS， DBGSSLCK， DBGSSLM， DBGSSLS）

这组寄存器用于控制和管理整个调试子系统的访问权限，特别是在多核、多上下文环境中，防止调试操作干扰正常的程序执行或被恶意利用。

• DBGSS (Offset 0x28): 调试子系统控制寄存器。目前仅包含一个EN位（bit 0），描述为“Non Secure context of CM33 can use this register to interrupt CM3”。这可能是一个笔误或特定于该芯片的用途，其功能更接近使能调试子系统对某个核心的访问或中断能力。需要结合芯片勘误表或更详细的应用笔记确认。
• DBGSSLCK (Offset 0x2C): 调试接口锁定寄存器。通过LOCK位实现一个简单的“锁”机制。
  • 读操作：读LOCK位。如果返回1，表示成功获得锁（当前无调试请求）；如果返回0，表示未获得锁（有调试请求正在进行），需要重试。
  • 写操作：写1强制获得锁（无视调试请求状态）；写0释放锁。
  • 类型：Write/Read-Clear。这意味着写操作有特定效果，而读操作可能清除某些状态（但此处描述为读返回值判断）。
• DBGSSLM (Offset 0x30): 锁条件掩码寄存器。MASK位（bit 1）用于在检查锁条件时，是否屏蔽（忽略）调试请求。设置为1则在检查锁时屏蔽请求。
• DBGSSLS (Offset 0x34): 锁条件状态寄存器。只读，用于查看调试子系统的状态。
  • FRCACT：调试主机强制激活状态。
  • CSYSPWRREQ：调试主机C系统电源请求状态。

典型使用模式（安全临界代码段保护）：在进入一段对时序或状态极其敏感的安全关键代码（如密码学操作、安全启动验证）时，我们希望暂时阻止调试器的访问，防止其单步或断点操作引入不可预测的延迟或泄露敏感信息。

#define DBGSSLCK_REG (*(volatile uint32_t *)(HOST_MCU_BASE + 0x2CU)) #define DBGSSLM_REG (*(volatile uint32_t *)(HOST_MCU_BASE + 0x30U)) void enter_secure_critical_section(void) { uint32_t lock_acquired = 0; // 可选：在尝试获取锁时，屏蔽调试请求，确保一定能进入 DBGSSLM_REG = (1U << 1); // 设置MASK=1 // 尝试获取调试接口锁 // 注意：根据手册，读操作返回1表示获得锁。但描述也提到“Try to read again”如果读0。 // 这里实现一个简单的重试机制。 for(int i = 0; i < 10; i++) { if ((DBGSSLCK_REG & 0x1U) != 0) { lock_acquired = 1; break; } // 短暂延迟 __NOP(); __NOP(); __NOP(); } if (!lock_acquired) { // 如果无法自然获得锁，强制获取（可能会中断正在进行的调试会话，需谨慎） DBGSSLCK_REG = 0x00000001U; // 写1强制获取锁 } // 执行安全关键代码... // ... } void exit_secure_critical_section(void) { // 释放调试接口锁 DBGSSLCK_REG = 0x00000000U; // 写0释放锁 // 恢复锁条件掩码 DBGSSLM_REG = 0x00000000U; }

严重警告：强制获取调试锁（写DBGSSLCK为1）会中断可能正在进行的调试会话，导致调试器失去连接或产生不可预知的行为。此操作应仅用于产品最终部署前的安全引导等极端场景，在开发阶段慎用。通常，更好的做法是通过调试器本身提供的命令或芯片的调试认证接口来安全地禁用调试功能。

3. TPIU寄存器配置与跟踪数据输出实战

TPIU是CoreSight跟踪架构中的关键组件，它负责将内部并行的跟踪数据流（来自ITM, DWT, ETM）序列化，并通过有限的引脚（SWO或TracePort）输出到芯片外部。配置好TPIU，是使用SWO或跟踪端口进行代码跟踪、性能分析的前提。

3.1 同步端口大小与协议选择（SSPSR， CSPSR， SPPR）

在连接外部调试探头前，必须确保TPIU的输出端口大小和协议与探头支持的模式匹配。

• SSPSR (Supported Sync Port Sizes): 只读寄存器，指示硬件支持的同步端口宽度。从手册看，该TPIU支持1-bit、2-bit和4-bit宽度（ONE,TWO,FOUR位为1），不支持3-bit。
• CSPSR (Current Sync Port Size): 可读写，用于设置当前使用的端口宽度。重要限制：只能设置一个位为1，且该位必须在SSPSR中指示为支持。复位后默认为1-bit模式（ONE=1）。如果你使用4线TracePort，就需要将其设置为4-bit模式。
• SPPR (Selected Pin Protocol): 选择引脚协议。
  • 0x00: TracePort模式。使用多条数据线（与CSPSR设置的宽度对应）和一条时钟线，带宽最高。
  • 0x01: 串行线输出（SWO）曼彻斯特编码。这是复位默认值。使用单根线，数据通过曼彻斯特编码传输，自带时钟信息，抗干扰性好，但带宽较低。
  • 0x02: 串行线输出（SWO）NRZ（不归零）编码。同样使用单根线，但编码效率高于曼彻斯特，需要独立的时钟参考（���常由调试器提供或使用异步模式）。

配置流程示例（切换到4-bit TracePort模式）：

// 假设TPIU寄存器基地址为0xE0040000（这是Cortex-M系列常见的TPIU地址，实际需查表） #define TPIU_BASE (0xE0040000U) #define SSPSR_REG (*(volatile uint32_t *)(TPIU_BASE + 0x00U)) #define CSPSR_REG (*(volatile uint32_t *)(TPIU_BASE + 0x04U)) #define SPPR_REG (*(volatile uint32_t *)(TPIU_BASE + 0xF0U)) void configure_tpiu_for_traceport(void) { uint32_t supported_sizes; uint32_t current_protocol; // 1. 检查硬件是否支持4-bit端口 supported_sizes = SSPSR_REG; if (!(supported_sizes & (1U << 3))) { // 检查FOUR位 // 硬件不支持4-bit TracePort，回退到1-bit SWO // 或者报错处理 return; } // 2. 在更改协议前，确保没有跟踪数据正在输出（通常需要停止跟踪源） // 可以通过控制ITM/DWT/ETM的使能寄存器来实现，此处略。 // 3. 先设置端口大小 CSPSR_REG = 0x00000000U; // 先全部清零 CSPSR_REG = (1U << 3); // 仅设置FOUR位为1，启用4-bit端口 // 4. 再设置引脚协议为TracePort模式 current_protocol = SPPR_REG; current_protocol &= ~0x00000003U; // 清除PROTOCOL字段 current_protocol |= 0x00000000U; // 设置为0x00 (TracePort) SPPR_REG = current_protocol; // 5. 重新使能跟踪源... }

核心要点：SPPR寄存器的描述中有一个关键警告：“If this register is changed while trace data is being output, data corruption occurs.” 这意味着在切换协议（例如从SWO切换到TracePort）时，必须确保TPIU没有正在格式化输出数据。通常的做法是：先禁用ITM、DWT、ETM等跟踪数据源，然后配置TPIU，最后再重新使能跟踪源。此外，CSPSR的设置必须与物理连接（调试探头连接的引脚数量）严格一致，否则跟踪数据无法被正确捕获。

3.2 异步时钟预分频与波特率计算（ACPR）

当使用SWO（异步串行）模式时，ACPR寄存器用于设置输出波特率。跟踪时钟（tpiu_trace_clk_in）经过(PRESCALER + 1)分频后，产生SWO的位速率。

计算公式：SWO_BaudRate = tpiu_trace_clk_in / (PRESCALER + 1)

配置示例：假设输入跟踪时钟为80MHz，我们希望SWO波特率为2Mbps。

#define ACPR_REG (*(volatile uint32_t *)(TPIU_BASE + 0x10U)) void configure_swo_baudrate(uint32_t trace_clk_hz, uint32_t desired_baudrate) { uint32_t prescaler; // 计算预分频值，并向下取整确保不高于目标波特率 prescaler = (trace_clk_hz / desired_baudrate) - 1; // 检查是否在13位范围内 (0-8191) if (prescaler > 0x1FFF) { prescaler = 0x1FFF; // 设置为最大值 } // 写入ACPR寄存器，注意PRESCALER在bit[12:0] ACPR_REG = (prescaler & 0x00001FFFU); } // 调用 configure_swo_baudrate(80000000, 2000000); // 80MHz时钟，目标2Mbps

计算过程：80000000 / 2000000 = 40，40 - 1 = 39(0x27)。所以PRESCALER应设置为39。

调试经验：SWO波特率设置不匹配是导致调试器收不到跟踪数据的最常见原因之一。务必确认三点：1)tpiu_trace_clk_in的实际频率（它可能来自系统主频，也可能经过TRACECFG分频）；2) 计算出的PRESCALER值在0-8191范围内；3) 调试探针的SWO接口波特率设置必须与TPIU计算的波特率完全一致。许多高级调试器（如SEGGER Ozone， Lauterbach Trace32）支持自动波特率检测，但在手动配置时，这里容易出错。

3.3 格式化器与同步控制（FFCR， PSCR）

这两个寄存器控制跟踪数据的格式化方式和同步机制。

• FFCR (Formatter and Flush Control):
  • ENFCONT(Bit 1): 使能连续格式化。当使用SWO模式时，如果此位为0，则格式化器可能在某些条件下停止，导致数据流中断。通常建议保持为1（默认），以确保数据流连续。
  • TRIGIN(Bit 8): 指示当触发引脚被断言时是否插入触发包。这对于在跟踪流中标记外部触发事件很有用。
• PSCR (Periodic Synchronization Counter):
  • PSCOUNT(Bits [4:0]): 周期性同步计数器重载值。TPIU会在输出一定数量的字节后，自动插入一个同步帧（Sync Frame），帮助接收端（调试探针）在数据流丢失后重新对齐。0b00000禁用同步。其他值定义同步间隔，例如0b00111表示每128字节插入一个同步帧。

配置建议：对于大多数应用，使用默认值即可。但在以下情况可能需要调整：

1. 长距离或噪声环境：减小PSCR的值（即增加同步频率），例如设置为每128或256字节同步一次，可以提高数据流的鲁棒性。
2. 节省带宽：如果跟踪数据量巨大，且链路质量很好，可以增大PSCR值或禁用同步，以减少同步帧的开销。但风险是一旦失步，后续数据可能全部无法解析。

#define FFCR_REG (*(volatile uint32_t *)(TPIU_BASE + 0x304U)) #define PSCR_REG (*(volatile uint32_t *)(TPIU_BASE + 0x308U)) void configure_tpiu_formatter(void) { // 确保连续格式化使能，这是稳定输出SWO数据所必需的 uint32_t ffcr_val = FFCR_REG; ffcr_val |= (1U << 1); // 设置ENFCONT=1 FFCR_REG = ffcr_val; // 配置为每256字节插入一个同步帧 (PSCOUNT = 0b01000) uint32_t pscr_val = PSCR_REG; pscr_val &= ~(0x1FU << 0); // 清除PSCOUNT字段 pscr_val |= (0x08U << 0); // 设置为0b01000 (256字节) PSCR_REG = pscr_val; }

3.4 声明标签寄存器（CLAIMMASK， CLAIMSET， CLAIMTAG， CLAIMCLR）

这组寄存器是CoreSight架构的标准部分，用于管理多路调试工具对同一跟踪资源的访问。它们实现了一个简单的“声明标签”机制，允许多个调试代理（例如，一个片上诊断核心和一个外部调试器）协调使用TPIU。

• CLAIMMASK：只读，指示哪些声明标签位是有效的（可用的）。例如，读回0xF表示低4位可用。
• CLAIMSET：写此寄存器可以“设置”（声明）某个标签位。写1到某位则声明该位。
• CLAIMTAG：只读，返回当前声明的标签值。
• CLAIMCLR：写此寄存器可以“清除”（释放）某个标签位。写1到某位则释放该位。

工作原理：一个调试代理想使用TPIU时，它会读取CLAIMMASK，然后尝试通过写CLAIMSET来声明一个空闲的标签位（通常从低位开始尝试）。成功后，该位在CLAIMTAG中会显示为1。使用完毕后，通过写CLAIMCLR来释放。如果两个代理试图声明同一位，硬件会协调。

在单调试器环境下的典型操作：在简单的开发场景中，通常只有一个外部调试器连接，它会在初始化跟踪时自动处理声明标签。但如果你在写底层驱动或固件，需要手动管理：

uint8_t claim_tpiu_channel(void) { uint32_t mask = CLAIMMASK_REG; for (int i = 0; i < 32; i++) { if (mask & (1U << i)) { // 该标签位可用 CLAIMSET_REG = (1U << i); // 尝试声明 // 短暂延迟后读取确认 if (CLAIMTAG_REG & (1U << i)) { return i; // 声明成功，返回标签位索引 } } } return 0xFF; // 声明失败 } void release_tpiu_channel(uint8_t channel_bit) { if (channel_bit < 32) { CLAIMCLR_REG = (1U << channel_bit); } }

注意：对于绝大多数使用标准调试软件（如Keil MDK， IAR Embedded Workbench， SEGGER J-Link软件）的开发者，无需直接操作这些寄存器，调试软件会妥善处理。只有当你设计自定义的调试主机或复杂的多核调试框架时，才需要关注它们。

4. 调试寄存器配置的常见问题与实战排查

即使按照手册配置了所有寄存器，跟踪功能仍然可能��法工作。以下是一些常见问题及其排查思路，这些都是从实际项目调试中积累的血泪经验。

4.1 跟踪引脚复用与硬件连接

问题现象：配置无误，但调试器无法检测到TPIU或SWO无数据。

排查步骤：

1. 检查引脚复用：TPIU/SWO信号（如TRACEDATA[3:0],TRACECLK,SWO）通常与普通GPIO复用。必须在芯片的引脚复用控制器（PinMux）中，将这些引脚配置为调试跟踪功能，而不是GPIO或其他外设功能。这是最容易被忽略的一步。
2. 确认硬件连接：
   • TracePort：需要连接TRACECLK和TRACEDATA[3:0]（根据CSPSR设置的宽度连接对应数量）到调试探针。时钟线通常需要上拉。
   • SWO：仅需连接SWO引脚。注意，SWO是单向输出，连接调试探针的对应输入即可。确保线缆质量良好，长距离或劣质线缆会导致信号完整性差。
3. 检查供电与电平：确保调试探针和芯片的供电电压匹配，特别是SWO引脚的电平。有些芯片的SWO输出电平可能与调试器输入电平不兼容。

4.2 时钟配置链路上的陷阱

问题现象：SWO数据乱码或时有时无。

排查步骤：

1. 理清时钟链：跟踪数据的最终输出速率取决于一个时钟链：系统时钟 -> （可能的分频）->tpiu_trace_clk_in->ACPR分频 -> SWO波特率。你需要逐级确认：
   • 系统主频是否正确配置并稳定？
   • TRACECFG.CLKDIVVAL和CLKDIVEN是否已正确设置，使得tpiu_trace_clk_in达到预期频率？
   • ACPR.PRESCALER计算值是否正确？用公式实际波特率 = tpiu_trace_clk_in / (PRESCALER + 1)验算。
2. 与调试器波特率同步：调试软件中设置的SWO波特率必须与芯片端ACPR计算出的波特率精确一致。即使有自动波特率检测，手动核对一次也是好习惯。可以尝试在调试器中微调波特率（如±5%）看是否能锁定信号。
3. 测量时钟：如果条件允许，使用示波器测量SWO引脚或TRACECLK引脚的波形，检查其频率是否与预期相符。

4.3 跟踪数据源未使能

问题现象：TPIU/SWO链路已通，但看不到预期的程序跟踪或数据跟踪信息。

排查步骤：

1. 使能ITM：ITM（Instrumentation Trace Macrocell）是用于软件插桩（如printf重定向）和软件生成消息的。需要配置ITM的TER（Trace Enable Register）寄存器来使能特定刺激端口（Stimulus Port），例如端口0常用于printf。

   // 使能ITM并解锁访问（Cortex-M标准操作） CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk; // 使能跟踪 ITM->LAR = 0xC5ACCE55; // 解锁ITM寄存器写访问 ITM->TER = 0x00000001; // 使能刺激端口0 ITM->TCR = 0x0001000D; // 使能ITM，同步数据包，并设置TraceBusID

2. 使能DWT：DWT（Data Watchpoint and Trace）用于硬件断点、观察点、程序计数器采样和异常跟踪。需要配置DWT的CTRL寄存器。

   // 使能DWT的异常跟踪和PC采样 DWT->CTRL |= (1UL << DWT_CTRL_EXCTRCENA_Pos) | (1UL << DWT_CTRL_PCSAMPLENA_Pos); // 根据需要配置CYCCNT计数器等 DWT->CYCCNT = 0; DWT->CTRL |= (1UL << DWT_CTRL_CYCCNTENA_Pos);

3. 使能ETM（如果芯片支持且需要指令跟踪）：ETM的配置更为复杂，涉及触发事件、地址范围、上下文ID等。通常需要调试器软件（如DS-5， Trace32）的图形化界面来配置。确保ETM已上电且使能。
4. 检查TPIU的输入端：TPIU的FFSR.FTNONSTOP位应读为1（表示格式化器无法停止，即正在接收数据）。如果为0，可能意味着上游跟踪源（ITM/DWT/ETM）没有数据送来。

4.4 多核与安全环境下的调试隔离

问题现象：在双核（M33+M3）或TrustZone环境下，只能调试一个核心或一个安全状态。

排查步骤：

1. 确认调试器连接：确保调试器已正确连接并识别出所有核心。有些调试探针需要特殊配置才能同时调试多核。
2. 检查系统控制寄存器：Cortex-M33的DEMCR（Debug Exception and Monitor Control Register）等寄存器可能控制着非安全/安全世界的调试权限。需要确保调试器有足够的权限访问目标上下文。
3. 利用HOST_MCU寄存器：如前所述，NSSWIRQ和SWIRQCM3等寄存器可以用于核间触发调试事件或中断，这可以作为辅助调试手段。例如，在M3核心中设置一个断点，当M33核心运行到特定位置时，通过写SWIRQCM3触发M3的断点。
4. 查阅芯片安全手册：调试功能可能受到芯片级安全策略的限制。某些安全启动或生产模式可能会永久或临时禁用调试接口。需要确认芯片是否处于允许调试的状态。

4.5 配置检查清单

在开始跟踪调试前，可以按照以下清单快速过一遍：

调试与跟踪系统的配置是一个环环相扣的过程，任何一个环节的疏漏都可能导致功能失效。最好的方法是增量测试：先配置最简单的SWO输出和ITM软件跟踪，发送一个字符，确认链路畅通。然后再逐步添加DWT的PC采样、异常跟踪，最后再尝试复杂的ETM指令跟踪。每次只改变一个变量，可以快速定位问题所在。记住，这些寄存器是你与芯片深处对话的桥梁，理解它们每一个比特的含义，就能在出现问题时，有的放矢地进行排查，而不是盲目地重启和祈祷。