嵌入式MCU深度调试：BDC与DBG模块原理、配置与实战应用
1. 嵌入式调试技术：从硬件断点到实时追踪
在嵌入式开发这个行当里，调试能力的高低，往往直接决定了项目是“优雅地解决问题”还是“痛苦地熬夜救火”。我们每天都在和那些看不见摸不着的寄存器、内存地址和时序打交道，当程序跑飞、变量被莫名篡改，或者某个中断死活不响应时，如果没有趁手的调试工具，那感觉就像在漆黑的房间里找一根针。今天，我想和你深入聊聊嵌入式微控制器内部的两个“神兵利器”——背景调试控制器（BDC）和片上调试模块（DBG）。它们不像JTAG或SWD那样广为人知，但在像Freescale/NXP的MC1323x这类集成了无线功能的微控制器中，它们是实现深度、非侵入式调试的基石。
简单来说，BDC是你的“后台遥控器”。它允许你在程序正常运行时（我们称之为“前台”或“用户模式”），通过一个简单的串行引脚（通常是BKGD），悄悄地给CPU发指令，让它暂停手头的工作，进入一个特殊的“背景调试模式”。在这个模式下，你可以像外科手术一样，精确地查看和修改内存、CPU寄存器，而这一切对正在运行的用户程序几乎是透明的。而DBG模块，则更像一个“行车记录仪”加“智能触发器”。它内置了硬件比较器，可以实时监控地址总线、数据总线，当程序执行到你预设的特定地址，或者访问了某个特定数据时，它能自动触发一系列动作：比如让CPU暂停，或者悄无声息地把关键的执行路径（比如函数调用、跳转地址）记录到一个内部的FIFO缓冲区里，供你事后分析。
为什么需要它们？想象一下，你的无线传感器节点在野外偶尔会死机，但用传统的断点停下来检查时，问题又消失了。这就是典型的“海森堡bug”——观察行为影响了被观察对象。BDC和DBG提供的硬件级调试支持，旨在以最小的侵入性，捕捉那些转瞬即逝的运行时状态。这对于开发实时系统、低功耗物联网设备以及复杂的无线协议栈（就像MC1323x所擅长的Zigbee应用）至关重要。接下来，我将结合手册细节和实际调试经验，为你拆解它们的原理、配置方法和那些手册上不会写的“避坑指南”。
2. 背景调试控制器（BDC）深度解析
BDC是微控制器内部一个相对独立的硬件模块，它充当了外部调试器（主机）与CPU核心之间的桥梁。它的设计哲学是：尽可能少地干扰CPU，同时提供足够强大的控制能力。
2.1 核心机制：如何潜入后台
要让BDC工作，首先必须打开它的总开关，即设置BDC状态与控制寄存器（BDCSCR）中的ENBDM位为1。这是前提，如果这个位是0，所有BDC功能都将失效。手册中详细描述了五种进入背景调试模式的方法，每一种都有其特定的使用场景和细微差别。
2.1.1 BACKGROUND命令：最直接的呼叫
这是最常用、最“文明”的进入方式。当调试器通过BKGD引脚发送特定的BACKGROUND命令（操作码0x90）后，BDC会向CPU核心发出一个进入背景模式的请求。关键在于，这个请求不是立即执行的，CPU会在当前指令的边界处，根据事件优先级来处理这个请求。这保证了CPU不会在一条指令执行到一半时被粗暴打断，避免了内存或寄存器状态处于不一致的中间状态。
一旦CPU响应请求，它会执行一条特殊的BGND指令，从而正式进入背景调试模式，并置位BDCSCR中的BDMACT位。此时，CPU就像被按下了暂停键，但整个芯片的时钟和外设（取决于具体设计）可能仍在运行。在这个模式下，你可以执行两种命令：前台命令和后台命令。这里有个重要的概念区分：前台命令（如READ_BYTE, WRITE_BYTE）在CPU运行用户代码时（即非BDM模式）也能执行，这让你能“偷偷地”读写内存，而后台命令（如读写CPU寄存器A、HX、PC等）则只能在BDM激活时执行。
恢复执行有四个命令：GO、TRACE1、TAGGO和GO_UNTIL。最常用的是GO，它让CPU从被中断的地方继续执行。这里有一个极其关键的细节：只要你在BDM期间没有修改程序计数器（PC），并且没有更高优先级的事件（如中断） pending，CPU就会精确地从那条被中断的指令开始执行。这保证了调试行为的可预测性。
实操心得：在实际使用中，发送BACKGROUND命令后，务必通过读取BDCSCR寄存器的BDMACT位来确认CPU是否真的进入了BDM。特别是在干扰较大的环境中，串行通信可能出错。另外，使用GO命令恢复前，一定要检查并确认没有无意中修改过PC值，否则程序会飞到一个不可预料的地方，让你误以为是其他bug。
2.1.2 硬件断点：守株待兔的陷阱
这是功能更强大的进入方式。你可以在BDC断点寄存器（BDCBKPT）中设置一个地址。当CPU访问（读或写）到这个地址时，BDC的硬件比较电路会立即检测到匹配，并请求CPU进入BDM。这相当于在代码的特定位置设置了一个无形的陷阱。
配置硬件断点需要几步：
- 确保ENBDM=1。
- 通过WRITE_CONTROL命令，设置BDCSCR中的BKPTEN位为1，启用断点功能。
- 通过WRITE_BKPT命令，将你想要的断点地址写入BDCBKPT寄存器。
这里有一个重要的配置位：FTS。它决定了断点的触发方式。
- FTS=1：访问触发。任何对该地址的有效访问（读或写）都会立即触发断点。这非常适合用于监控某个变量的写入，或者捕获对特定函数的调用。
- FTS=0：指令标记。仅当该地址是一次“程序读”（即CPU从这里取指令）时，BDC会标记这条指令。当这条被标记的指令流到CPU流水线的顶端，即将被执行时，才会触发进入BDM。这允许你在某条指令执行之前暂停，而不是在访问其地址的时候。这对于调试精确的指令执行顺序非常有用。
避坑指南：硬件断点在BDM激活期间是自动禁用的。也就是说，当你因为一个断点而进入BDM后，在BDM期间，即使程序再次经过那个断点地址，也不会再次触发。这防止了断点的递归触发导致死循环。只有当你用GO等命令退出BDM后，断点才会重新生效。
2.1.3 BGND指令：程序自带的“调试后门”
你可以在你的应用程序代码中直接插入BGND指令的机器码。当CPU执行到这条指令时，只要ENBDM=1，它就会自动进入BDM。这就像在代码里埋了一个调试开关。恢复执行后，CPU会从BGND指令的下一条指令开始执行。
手册特别强调了一个安全机制：如果BGND指令位于受保护的“安全内存”中，它会被当作一个非法操作码处理，从而防止攻击者利用BDM模式绕过安全机制。其攻击路径可能是：先通过BACKGROUND命令进入BDM，然后恶意修改PC指向安全内存中的BGND指令，再用GO命令去执行它。芯片硬件层面的这个设计堵住了这个漏洞。
2.1.4 外部强制与标记（Force/Tag）
这是通过芯片外部引脚信号来触发进入BDM的方式。其行为与内部的Force/Tag类似，但如果此时BDM未被启用（ENBDM=0），CPU会转而执行一个软件中断（SWI）指令，并设置相关的状态信号。这个机制通常用于更底层的芯片测试或特殊的调试场景。
2.2 BDC命令集：与芯片对话的语言
BDC通过一套定义好的串行协议在BKGD引脚上与主机通信。所有数据都是高位（MSB）在先。命令分为前台和后台两大类，这个分类至关重要。
为了让命令结构更清晰，我将其整理成下表。理解命令结构中的符号���读懂手册的关键：
| 符号 | 描述 |
|---|---|
| OP | 8位操作码（主机->目标） |
| / | 命令各部分的分隔符 |
| d | 延迟16个时钟周期（基于串行通信的参考时钟） |
| AAAA | 16位地址（主机->目标） |
| SS | 从BDCSCR读取的8位状态数据（目标->主机） |
| CC | 写入BDCSCR的8位数据（主机->目标） |
| RB/WB | 读写8位数据 |
| RBKP/WBKP | 读写16位断点寄存器数据 |
| RHWD/WHWD | 读写16位数据（用于HX、SP、PC等寄存器） |
2.2.1 前台命令（CPU运行时可执行）
这些命令允许调试器在程序运行时“窥探”系统，而不必停止它。
| 命令 | 操作码 | 命令结构 | 描述与使用场景 |
|---|---|---|---|
| SYNC | 无 | 无 | 特殊命令，通过拉低BKGD超过128个周期来请求一个同步脉冲，用于波特率检测和通信同步。 |
| ACK_ENABLE | 0xD5 | OP/d | 启用硬件握手协议。启用后，目标芯片在某些命令执行后会发出一个ACK确认脉冲。 |
| ACK_DISABLE | 0xD6 | OP/d | 禁用硬件握手协议。 |
| BACKGROUND | 0x90 | OP/d | 请求进入背景调试模式。前提是ENBDM必须为1。 |
| READ_STATUS | 0xE4 | OP/SS | 读取BDCSCR寄存器，获取当前BDC状态（如BDMACT, ENBDM等）。 |
| WRITE_CONTROL | 0xC4 | OP/CC | 写入BDCSCR寄存器，用于配置BDC（如开启/关闭BDM，启用断点）。 |
| READ_BYTE | 0xE0 | OP/AAAA/d/RB | 从指定内存地址（AAAA）读取一个字节。这是最常用的内存查看命令。 |
| WRITE_BYTE | 0xC0 | OP/AAAA/WB/d | 向指定内存地址（AAAA）写入一个字节（WB）。这是最常用的内存修改命令。 |
| READ_BKPT | 0xE2 | OP/RBKP | 读取当前设置的硬件断点地址。 |
| WRITE_BKPT | 0xC2 | OP/WBKP | 设置硬件断点地址。 |
2.2.2 后台命令（仅BDM激活时可执行）
这些命令用于在CPU暂停时，深度检查和控制其核心状态。
| 命令 | 操作码 | 命令结构 | 描述与使用场景 |
|---|---|---|---|
| GO | 0x08 | OP/d | 退出BDM，恢复用户程序执行。 |
| GO_UNTIL | 0x0C | OP/d | 恢复执行，但运行直到遇到一个激活的硬件断点，然后再次进入BDM。这是实现“运行到断点”功能的核心。 |
| TRACE1 | 0x10 | OP/d | 单步执行一条用户指令，然后自动返回BDM。这是最基础的代码级单步调试。 |
| TAGGO | 0x18 | OP/d | 与GO类似，但不发出ACK脉冲。用于不需要握手确认的场景。 |
| READ_A / WRITE_A | 0x68/0x48 | OP/d/RB 或 OP/WB/d | 读写累加器A。 |
| READ_HX / WRITE_HX | 0x6C/0x4C | OP/d/RHWD 或 OP/WHWD/d | 读写16位索引寄存器H:X。 |
| READ_SP / WRITE_SP | 0x6F/0x4F | OP/d/RHWD 或 OP/WHWD/d | 读写堆栈指针SP。修改SP要极度小心，错误的SP会导致程序崩溃。 |
| READ_PC / WRITE_PC | 0x6B/0x4B | OP/d/RHWD 或 OP/WHWD/d | 读写程序计数器PC。这是最强大的命令之一，直接控制程序流。 |
| READ_NEXT / WRITE_NEXT | 0x70/0x50 | OP/d/RB 或 OP/WB/d | 先让H:X寄存器加1，然后读写H:X指向的内存。这非常适合遍历数组或缓冲区。 |
2.2.3 串行通信与超时机制
BDC通信时钟可以源自两个时钟源：本地振荡器（异步于CPU总线时钟）或CPU总线时钟的2分频（同步）。通过BDCSCR的CLKSW位选择。
超时机制是为了防止通信挂死。如果主机在发起一个命令（BKGD下降沿）后，在512个串行时钟周期内没有完成整个命令的发送或数据的读取，BDC会执行一次“软复位”，丢弃当前未完成的操作，等待下一个命令开始。这保证了即使主机调试器意外崩溃或断开，目标芯片也不会被锁死。
重要提示：当硬件握手协议启用时，对于读命令，在ACK脉冲发出之前，超时机制是被禁用的。这是因为BDC时钟可能远快于CPU时钟，数据可能还没准备好。但ACK脉冲发出后，主机必须在接下来的512个周期内取走数据，否则数据将丢失。这个细节在编写底层调试器驱动时必须妥善处理。
3. 片上调试模块（DBG）与实时追踪
如果说BDC提供了基础的停止-查看功能，那么DBG模块则提供了更高级的、带触发条件的实时数据捕获能力，它更像一个集成在芯片内的逻辑分析仪。
3.1 DBG模块架构与工作原理
DBG模块由三个核心部分组成：比较器（Comparator）、触发中断控制逻辑（TBC）和先入先出缓冲区（FIFO）。它的工作流程可以概括为：比较器实时监控总线活动 -> 当匹配条件满足时，TBC根据配置决定是否触发 -> 触发后，根据模式决定是开始还是停止向FIFO记录数据，以及是否请求CPU断点。
3.1.1 比较器：三位哨兵
DBG模块包含三个独立的硬件比较器：A、B和C。
- 比较器A和B：是功能主力。在大多数模式下，它们比较地址总线与用户预设的地址（分别存储在DBGCAX/H/L和DBGCBX/H/L寄存器中）。但在“全模式”（Full Mode）下，比较器B可以切换为比较数据总线与DBGCBL寄存器中的值。这实现了“当访问地址0x1000且写入的数据为0x55时触发”这类复杂条件。
- 比较器C：通常作为第三个硬件断点使用。但在一种特殊的“LOOP1捕获模式”下，它被DBG模块内部逻辑用来跟踪最近一次捕获到FIFO中的“程序流改变事件”的地址，用于去重，防止FIFO被重复的跳转地址填满。
3.1.2 断点请求类型：标记型与强制型
DBG模块支持两种断点请求，由DBGC寄存器中的TAG位决定：
- 强制型断点（TAG=0）：触发后，CPU在下一个指令边界立即进入背景调试模式。响应迅速，但不够精确。
- 标记型断点（TAG=1）：触发后，该断点地址被“标记”并送入CPU的指令队列。只有当这个被标记的指令流到队列头部，即将被执行前，CPU才会进入BDM。这确保了断点精确地发生在你希望的那条指令上，而不是在取指周期。
3.1.3 触发模式：九种武器
DBG提供了九种灵活的触发模式，通过DBGT寄存器配置。这些模式决定了比较器A和B的信号如何组合才能构成一个“触发事件”。以下是几种关键模式：
| 触发模式 | 描述 | 典型应用场景 |
|---|---|---|
| A Only | 仅比较器A匹配时触发。 | 简单的地址断点。 |
| A OR B | 比较器A或B匹配时触发。 | 监控两个可能的函数入口点。 |
| A Then B | 先匹配A，之后再匹配B时触发。 | 捕获从函数A进入函数B的特定路径。 |
| A And B (Full Mode) | 同一总线周期内，地址总线匹配A且数据总线匹配B时触发。 | 捕获向特定地址写入特定值的操作。 |
| A And Not B (Full Mode) | 同一总线周期内，地址总线匹配A且数据总线不匹配B时触发。 | 捕获向特定地址写入非预期值的错误。 |
| Inside Range (A ≤ addr ≤ B) | 当地址落在[A, B]区间内时触发。 | 监控对某一内存区域（如堆、栈）的任何访问。 |
| Outside Range (addr < A or addr > B) | 当地址落在[A, B]区间外时触发。 | 检测非法内存访问（如数组越界）。 |
| Event Only B | 仅由比较器B的事件（数据匹配）触发，且为开始触发类型。 | 专注于捕获特定的数据值，忽略地址。 |
3.1.4 开始触发与结束触发
这是DBG模块数据捕获逻辑的核心概念，由DBGT寄存器的BEGIN位控制：
- 开始触发（BEGIN=1）：当触发条件满足时，开始向FIFO记录数据，直到FIFO存满（8个字）为止。这用于捕获触发点之后的程序流。
- 结束触发（BEGIN=0）：从DBG模块被“武装”（ARM）开始，就持续向FIFO记录数据。当触发条件满足时，停止记录。这用于捕获导致触发点之前的程序流，相当于一个“回溯缓冲区”。
3.2 实战配置：一个完整的调试会话示例
假设我们正在调试一个基于MC1323x的无线传感器网络节点，发现它偶尔在发送数据包后卡死。我们怀疑是某个中断服务程序（ISR）在修改共享数据时出了问题。我们可以利用DBG模块来捕获程序流。
目标：捕获从地址0x1234（假设是发送函数入口）执行后，到地址0x5678（一个关键的共享变量地址）被写入之前，所有的程序流改变（函数调用、跳转、中断返回）。
步骤1：启用与武装DBG
- 首先，通过BDC命令（WRITE_BYTE）设置DBGC寄存器，将DBGEN位和ARM位置1，启用并武装DBG模块。同时，根据需求设置BRKEN（是否触发CPU断点）和TAG（断点类型）。
步骤2：配置比较器与触发模式2. 设置比较器A的地址寄存器（DBGCAX/H/L）为0x1234。 3. 设置比较器B的地址寄存器（DBGCBX/H/L）为0x5678。因为我们关心的是“写入”操作，所以需要配置为全模式（Full Mode），并设置RWAEN=1， RWA=0来选择写比较。 4. 配置DBGT寄存器： * 触发模式选择“A Then B”。这确保了顺序：先经过发送函数，再发生对共享变量的写入。 * 设置BEGIN=0（结束触发）。我们希望捕获从武装开始，到对0x5678写入之前的所有流改变事件。 * 设置TRGSEL。如果我们希望精确地在0x1234的指令被执行时触发A，而不是仅仅访问该地址，则设置TRGSEL=1（启用操作码追踪）。对B亦然。 5. 如果希望在触发时也让CPU暂停，则设置DBGC中的BRKEN=1，并根据TRGSEL的设置，匹配地设置TAG位（TRGSEL=1时，TAG也应=1，以保证断点发生在正确的指令位置）。
步骤3：运行与捕获6. 通过BDC发送GO命令，让程序运行。 7. 当程序执行到0x1234，然后后续对0x5678进行写入时，触发条件满足。DBG模块停止向FIFO记录数据，并可能请求CPU断点（如果BRKEN=1）。 8. 此时，DBGC中的ARM位会被硬件自动清零，表示一次追踪运行结束。
步骤4：读取与分析数据9. 通过BDC命令读取DBGCNT寄存器，获取FIFO中有效数据的数量（CNT位）。 10. 循环读取DBGFX（扩展信息）、DBGFH（地址高字节）和DBGFL（地址低字节）寄存器。每次读DBGFL，FIFO指针会自动前进。这些数据就是被捕获的程序流改变地址。 11. 分析这些地址序列，就能清晰地看到从发送函数开始，到写入共享变量之前，程序究竟经历了哪些函数调用、跳转和中断。这比单纯设个断点停下来看调用栈要强大得多，因为它记录了完整的历史路径。
3.3 关键寄存器详解与配置表
为了更直观地进行配置，我将DBG相关核心寄存器的关键控制位总结如下：
DBGC (调试控制寄存器)
| 位 | 名称 | 功能描述 |
|---|---|---|
| 7 | DBGEN | DBG模块总使能。1=启用。 |
| 6 | ARM | 武装位。1=启动一次追踪运行。触发后硬件自动清零。 |
| 5 | BRKEN | 断点使能。1=当触发条件满足时，向CPU请求断点。 |
| 4 | TAG | 断点类型。0=强制型断点；1=标记型断点。 |
DBGT (调试触发寄存器)
| 位 | 名称 | 功能描述 |
|---|---|---|
| 7 | BEGIN | 触发类型。0=结束触发；1=开始触发。 |
| 6 | TRGSEL | 触发选择。0=仅地址匹配；1=地址匹配且为操作码（指令）。 |
| [3:0] | TRGMOD | 触发模式。0000=A Only; 0001=A OR B; 0010=A Then B; ... 详见手册表17-16。 |
DBGS (调试状态寄存器)
| 位 | 名称 | 功能描述 |
|---|---|---|
| 7 | AF | 比较器A触发标志。 |
| 6 | BF | 比较器B触发标志。 |
| 5 | CF | 比较器C触发标志（或在LOOP1模式下去重指示）。 |
| 4 | ARMF | 武装标志。为1时表示DBG已武装且正在运行。 |
经验之谈：手册中的表17-23（调试运行基本类型）是配置时的金科玉律。它清晰地列出了BEGIN、TRGSEL、BRKEN、TAG这四个关键位的合法组合。例如，在结束触发模式（BEGIN=0）下，如果启用了CPU断点（BRKEN=1），那么TRGSEL和TAG必须一致（同为0或同为1），否则会导致断点触发时机与FIFO停止捕获的时机错位，使调试数据失去意义。在开始触发模式（BEGIN=1）下，则不应设置TAG=1，因为此时CPU断点是由FIFO满触发的，与指令标记无关。
4. 调试策略与高级应用场景
掌握了BDC和DBG的基本操作后，如何将它们组合起来，解决实际开发中的复杂问题，才是体现功力的地方。
4.1 组合使用BDC与DBG进行系统级诊断
BDC和DBG不是互斥的，而是互补的。一个典型的深度调试流程可能是这样的：
- 初步定位（使用BDC硬件断点）：在疑似出问题的函数入口或变量访问处设置BDC硬件断点。当程序停住后，使用BDC后台命令快速检查堆栈指针、关键变量和寄存器状态。这能帮你快速确认问题发生的上下文。
- 动态探查（使用BDC前台命令）：如果问题难以稳定复现，不适合频繁断点。可以在程序运行时，用BDC前台命令（如READ_BYTE）周期性地“偷看”某个状态变量或标志位。这几乎不影响程序实时性。
- 历史回溯（使用DBG追踪）：当问题发生时（比如系统看门狗复位），我们往往失去了现场。此时可以在系统初始化后立即武装DBG模块，配置为结束触发模式，触发地址设置为导致复位的关键函数或异常向量入口。这样，在复位前的那一刻，FIFO里已经保存了导致崩溃的最后一系列程序流改变。复位后，通过BDC读取FIFO，就能进行“尸检”，分析死机前的调用路径。
- 条件触发与过滤（DBG高级模式）：对于数据损坏问题，可以使用“A And B”全模式。将A设置为变量地址，B设置为一个非法值（如0xFF）。当程序向该变量写入这个非法值时，DBG立即触发并记录现场。对于排查随机覆盖内存的问题，可以使用“Outside Range”模式，监控栈空间或堆空间之外的访问，捕捉越界写。
4.2 针对无线协议栈的调试技巧
MC1323x常用于Zigbee等协议栈。调试协议栈时，挑战在于其高度事件驱动和实时性。
- 时间相关bug：避免在协议栈的严格时序部分（如MAC层ACK等待期间）使用会暂停CPU的标记型断点或强制型断点，这会导致超时。此时应优先使用DBG的非侵入式追踪（BRKEN=0），仅记录数据而不中断CPU，事后再分析。
- 状态机跟踪：协议栈通常是一个状态机。你可以将DBG比较器A设置为状态变量地址，使用“A Only”的结束触发模式。每次状态变量改变（这本身不是流改变，可能不会被FIFO捕获），你可以通过软件在状态改变处插入一个到空函数（其地址由比较器B监控）的调用，从而间接地将状态变迁记录到FIFO中。
- 中断嵌套问题：使用DBG捕获中断流。设置比较器监控中断向量表地址区域。结合“开始触发”模式，可以在中断发生时开始记录，看看是否有更高优先级的中断打断当前中断，导致某些关键操作未完成。
4.3 常见问题排查与避坑指南
BDC无法连接或命令无响应
- 检查时钟：确认芯片的时钟���已启动且稳定。BDC通信依赖于目标芯片的时钟。
- 确认复位状态：有些芯片在特定复位源（如看门狗复位）后，可能会暂时禁用调试接口。检查相关配置位。
- BKGD引脚配置：确保BKGD引脚未被复用为普通GPIO，并且上拉电阻正确。
- 通信速率：如果使用异步本地振荡器模式（CLKSW=0），主机调试器必须能适应较宽的波特率范围。同步模式（CLKSW=1）时序更确定。
硬件断点不触发
- ENBDM和BKPTEN：双重确认BDCSCR中的ENBDM和BKPTEN位都已正确置1。
- 地址对齐：确认设置的断点地址是有效的、可访问的地址。对于某些架构，指令断点可能需要字对齐。
- FTS位：明确你的需求是“访问触发”还是“指令标记触发”，正确配置FTS位。
- 内存保护：如果断点地址位于写保护或加密的内存区域，断点可能无效。
DBG FIFO读不到数据或数据不对
- ARM状态：只有在ARM=0（追踪已结束）时，读取FIFO的数据才是稳定有效的。在ARMF=1时读取，得到的是瞬时值，可能不准确。
- 触发模式与BEGIN不匹配：例如，在“事件仅B”模式下，BEGIN位是被忽略的，固定为开始触发。如果误配置为结束触发，逻辑会混乱。
- 流改变事件不足：DBG FIFO只记录“程序流改变事件”，即跳转、调用、返回等。如果两处触发点之间的代码完全是顺序执行，没有发生流改变，那么FIFO将是空的。此时需要结合软件插桩来产生记录点。
- FIFO溢出：FIFO只有8级深度。在复杂的程序流中，触发点之前的事件可能超过8个，最早的事件会被覆盖。需要合理设置触发点，或者通过多次实验来捕捉关键片段。
调试行为影响程序正常功能（海森堡效应）
- 最小化侵入：尽量使用DBG追踪而非CPU断点。如果必须断点，使用标记型断点（TAG=1）比强制型（TAG=0）对流水线的影响更小。
- 避免在关键时序中调试：识别出代码中对时序敏感的部分（如射频收发、精确延时），避免在这些区域设置断点或进行密集的内存读取操作。
- 理解外设继续运行：进入BDM后，CPU核心暂停，但许多外设（定时器、通信接口）可能仍在运行。这可能导致缓冲区溢出或状态超时。在恢复执行前，需要检查并清理相关外设状态。
嵌入式调试是一门实践的艺术，BDC和DBG提供了强大的底层工具。真正的熟练来自于在具体项目中的反复运用和踩坑。从简单的内存查看，到复杂的条件触发与程序流重构，这些硬件模块将调试从“猜谜游戏”变成了可观测、可分析的工程过程。对于MC1323x这类集成复杂无线功能的芯片，善用这些调试资源，是保证项目成功交付不可或缺的能力。