ARM Cortex-M7与Cortex-M33微控制器中DebugMonitor异常机制的深入解析与远程调试实践
I. 引言：实时系统调试的挑战与DebugMonitor的架构定位
1.1 传统侵入式调试（Halting Debug）的局限性
嵌入式系统开发人员长期以来依赖的核心调试方法是中止式调试（Halting Debug）。在这一模式下，当处理器遇到调试事件（例如硬件断点或观察点）时，通过设置调试暂停和控制状态寄存器（DHCSR）中的特定位，中央处理单元（CPU）会进入完全中止（Halt）状态¹。这种调试方式一般由上位机配合一个硬件调试器实现对MCU的完全接管。
这种方法对于开发阶段的逻辑验证是有效的，但在复杂的实时应用中，其弊端是致命的。当核心进入 Halting 状态时，嵌套向量中断控制器（NVIC）管理的所有中断都将被阻塞。对于时间敏感型任务，如处理高速通信协议栈（如 CAN-FD、以太网）或维持实时操作系统（RTOS）的心跳和调度，任何毫秒级的延迟都可能导致看门狗定时器复位、通信超时或数据完整性破坏²。
在远程调试场景中，Halting Debug 尤其矛盾。如果调试器通过网络链路（例如通过 CAN-FD 链路）与目标设备通信，一旦目标核心因命中断点而中止，它将无法处理任何入站的网络命令，包括通知其恢复执行（Resume）的命令，从而导致调试链路永久断开。因此，对于需要连续通信或严格实时性保证的系统，必须采用非中止式的调试策略。
1.2 Cortex-M架构的调试模式概述与DBGMON的定位
为了解决 Halting Debug 的实时性破坏问题，ARM Cortex-M架构（特别是 M3、M4、M7 和 M33 等更高级版本）引入了 DebugMonitor 异常。需要注意的是，Cortex-M0 和 M0+ 架构不支持 Debug Monitor 异常⁴。DebugMonitor（DBGMON）提供了所谓的“监控模式调试”（Monitor Mode Debugging）或“非中止式调试”（Non-halting Debugging）途径²。
Monitor Mode Debugging 的核心思想是将调试事件的响应从硬件强制的完全中止状态，转化为一个可配置优先级的系统异常。当发生调试事件时，处理器进入 DebugMonitor 异常处理程序（ISR）而不是 Debug State。这使得系统的高优先级中断仍能继续被服务，从而保障了关键任务的实时执行³。DBGMON 的优先级是可配置的，这允许系统架构师精细地控制调试对实时性能的影响，这与 HardFault 或 NMI 这种固定高优先级的异常形成了鲜明对比⁵。
这种架构特性是 Cortex-M7 和 Cortex-M33 在复杂实时系统调试能力上优于 M0/M0+ 的关键分水岭⁴。所有高级远程调试解决方案，特别是那些依赖于通信链路保持活跃的方案，都必须依赖于这一架构特性。
基于 DebugMonitor 这种可以配置中断优先级的调试方式，应用中针对调试方式的实现不再局限于SWD、JTAG这种传统的调试方式，而是可以实现基于普通通信接口，比如CAN、LIN、以太网、UART、SPI这些通信接口实现对MCU运行程序的调试。这种基于总线的调试方式在调试端口受限的汽车电子或者无线应用中可以直接复用现有通信网络，实现对多节点ECU的调试。
II. DebugMonitor的架构原理与控制机制深度解析
2.1 调试事件响应的层次与模式切换
在 Cortex-M 处理器中，调试事件（Debug Event）包括硬件断点、数据观察点，或通过调试访问端口（DAP）发起的软件请求⁶。处理器对这些事件的响应遵循严格的层次结构：
- Halting Debug 模式： 如果 Halting Debug 被启用（通过设置
DHCSR.C_DEBUGEN），调试事件将导致处理器进入 Debug State 并完全中止¹。 - Monitor Mode 模式： 如果 Halting Debug 被禁用（
DHCSR.C_DEBUGEN = 0），并且 Debug Monitor 被启用（DEMCR.MON_EN = 1），那么调试事件将触发 DebugMonitor 异常，前提是 DBGMON 的组优先级高于当前的执行优先级¹。 - HardFault 升级模式： 这是最危险的配置。如果 Halting Debug 和 Debug Monitor 都被禁用 (
DHCSR.C_DEBUGEN = 0且DEMCR.MON_EN = 0)，此时如果发生断点调试事件，它将升级为 HardFault 异常¹。
由于 HardFault 拥有固定的、至少为 -1 的最高优先级⁵，这种配置错误将导致系统陷入非预期的 HardFault Handler，造成系统崩溃，无法继续调试。因此，在实现虚拟调试探针（VDP）固件时，必须在系统初始化阶段通过原子操作，确保 DHCSR 和 DEMCR 寄存器的配置遵循互斥性规则，避免两个模式同时禁用，保障系统鲁棒性。
DHCSR（Debug Halting Control and Status Register）
DHCSR 位于系统控制空间（SCS）地址 0xE000_EDF0，用于控制 Halting Debug 以及反映内核调试状态。对 DHCSR 的写操作需在高半字写入解锁键值 DBGKEY=0xA05F 才会生效。
| 位 | 名称 | 访问 | 复位值 | 描述 |
|---|---|---|---|---|
| 31:16 | DBGKEY | W | - | 写入 0xA05F 以解锁对 C_* 控制位的写访问；读为实现定义或保留。 |
| 25 | S_RESET_ST | RO | 0 | 自上次读取后发生过系统复位事件。读取该位清除。 |
| 24 | S_RETIRE_ST | RO | 0 | 指示自上次读取后至少有一条指令成功复位（完成执行）。读取清除。 |
| 19 | S_LOCKUP | RO | 0 | 内核处于 Lockup 状态。 |
| 18 | S_SLEEP | RO | 0 | 内核处于睡眠状态。 |
| 17 | S_HALT | RO | 0 | 内核处于 Halt（调试停止）状态。 |
| 16 | S_REGRDY | RO | 1 | 上一次通过调试端口的寄存器访问已完成，寄存器接口就绪。 |
| 5 | C_SNAPSTALL | RW | 0 | 使能“Snap stall”。允许在总线停滞时进行调试控制（实现相关）。 |
| 3 | C_MASKINTS | RW | 0 | 屏蔽可屏蔽中断（PRIMASK 语义）以便在调试时抑制中断干扰。 |
| 2 | C_STEP | RW | 0 | 单步执行；与 C_DEBUGEN 配合用于逐条指令执行。 |
| 1 | C_HALT | RW | 0 | 请求内核进入 Halt（调试停止）状态。 |
| 0 | C_DEBUGEN | RW | 0 | 使能 Halting Debug；清零则禁用 Halting Debug。 |
注意：对 C_* 控制位的写操作必须与 DBGKEY=0xA05F 同时写入同一写事务。例如，要请求 Halt，可写入：DBGKEY=0xA05F 且 C_HALT=1（其余位按需）。
2.2 核心控制寄存器：DEMCR (Debug Exception and Monitor Control Register)
DEMCR 是控制 DBGMON 行为的中心枢纽。它位于系统控制空间（SCS）内，主要通过 DAP 或在 VDP 固件内部进行配置和操作。以下是与 DebugMonitor 相关的关键位域：
| 位域 | 名称 | 位置 | 功能描述 | 在 VDP 中的作用 |
|---|---|---|---|---|
| MON_EN | Monitor Enable | 启用 DebugMonitor 异常。与 DHCSR.C_DEBUGEN 互斥⁸ | VDP 固件初始化时必须置位，以捕获调试事件。 | |
| MON_PEND | Monitor Pending | 强制触发 DBGMON 异常。 | 调试器（通过 VDP 翻译）用于软件方式强制唤醒或中止目标，是远程 Halt 命令的核心机制⁸。 | |
| MON_STEP | Monitor Step | 使能单步调试。 | VDP 接收到 Step 命令后设置此位，控制 CPU 单条指令执行，实现受控返回和再抢占⁸。 |
MON_PEND 位提供了极高的灵活性：即使在 MON_EN=0（监控模式禁用）的情况下，外部调试器也可以通过 DAP 强制设置 MON_PEND=1，从而强制触发 DebugMonitor 异常⁸。这确保了即使核心处于某种不确定状态，调试器仍能通过软件中断机制可靠地接管控制权。
2.3 单步调试（Monitor Stepping）的机制与非确定性
Monitor Stepping 是一种专为 DBGMON 模式设计的单步执行机制。它允许处理器从 DBGMON 异常处理程序返回，执行单个指令，然后立即被 DebugMonitor 异常再次捕获。
其流程严格依赖于 DEMCR.MON_STEP 位⁹：
- VDP 固件接收 Step 命令后，设置 DEMCR.MON_STEP = 1。
- VDP 从 DebugMon_Handler 中返回，恢复被调试应用程序的上下文。
- 处理器执行被调试应用程序的下一条指令。
- 执行完成后，处理器自动设置 DEMCR.MON_PEND = 1。
- 处理器再次进入 DebugMon_Handler，控制权返回给 VDP。
关于非确定性的风险： 这种单步机制存在一个重要的潜在非确定性问题。在步骤 3（执行指令）和步骤 4（设置 MON_PEND）之间，如果存在一个优先级低于 DebugMonitor 异常但高于当前执行线程的挂起异常，处理器不会执行应用程序的下一条指令，而是执行该挂起异常的异常入口序列，然后立即被 DebugMonitor 抢占⁹。
这意味着 VDP 固件不能简单地假设单步操作执行了应用程序的一条指令。VDP 必须在下一次进入 Handler 时，仔细检查堆栈状态和程序计数器（PC）的值，以确定发生了实际的指令执行，还是仅仅完成了一次低优先级异常的入口序列。这种对返回状态的精细解析增加了 VDP 中单步逻辑的复杂性，要求开发者对 Cortex-M 的异常入栈机制有深刻理解，才能向 GDB 等调试前端报告正确的应用状态。
III. DebugMonitor在非中止式调试中的实践应用：以CAN-FD远程调试为例
3.1 虚拟调试探针（VDP）的核心概念
在基于 CAN-FD 的远程硬件调试应用中¹⁰，DebugMonitor 异常是实现“虚拟调试探针”（Virtual Debug Probe, VDP）的关键支撑。VDP 是一种运行在目标微控制器上的特殊固件层，它扮演了传统物理调试探针（如 J-Link 或 SWD 接口）的角色。
VDP 的核心功能是命令转换和状态映射：
- 接收与协议解析： VDP 通过 CAN-FD 链路接收远程调试器（例如 GDB 服务器）发出的标准调试命令。
- 命令翻译： VDP 将这些命令（如读取内存、设置观察点、执行 Step 或 Halt）翻译成对目标系统寄存器和内存位置的底层读写操作¹⁰。
- DHCSR 到 DEMCR 的映射： VDP 固件负责将标准 Halting Debug 中使用的 DHCSR 状态和事件，映射到 Monitor Mode 下的 DEMCR 寄存器操作。例如，外部调试器发出的 Halt 命令，会被 VDP 翻译为对 DEMCR.MON_PEND 的设置操作，从而触发 DBGMON 异常¹⁰。
3.2 基于 CAN-FD 的远程调试案例分析
CAN-FD（Controller Area Network Flexible Data-rate）因其高可靠性、高带宽和嵌入式系统的普及性，成为构建远程调试链路的优秀选择。
Halt 状态的实现：
- 当远程调试器发出 Halt 命令时，VDP 固件会通过设置 MON_PEND 来强制触发 DebugMonitor 异常¹⁰。
- 核心进入 DebugMon_Handler。
- Handler 中的汇编代码（通常是 naked 函数）保存上下文，并调用 VDP 的核心 C 语言逻辑（例如 enterDebugMode 函数）¹⁰。
- 该 C 语言逻辑分析当前状态，并进行上下文修正，确保调试器能够看到被中断的应用程序线程的堆栈和调用栈，而不是 DBGMON ISR 自身的上下文¹⁰。
- 最后，核心进入一个无限循环或基于状态机的驻留循环。目标系统只要处于该循环中，调试器就认为目标处于 Halt 状态。VDP 在该循环中持续通过 CAN-FD 接口与远程调试器进行通信，接收内存/寄存器读写请求或 Resume 命令。
中断优先级的严格管理：
远程调试的有效性完全依赖于通信链路在调试过程中必须保持活跃。这意味着负责处理 CAN-FD 通信的 CAN 中断服务程序（CAN ISR）的实时性必须高于 DebugMonitor ISR¹⁰。
- 优先级要求： 相对于DBGMON ISR，CAN ISR 必须配置为更高优先级（在 NVIC 中表现为数值更低）。
- 机制： 当核心被困在 DebugMonitor 的驻留循环中时，如果有新的 CAN 报文到达，CAN ISR 必须能够抢占（Preempt）DBGMON 异常¹⁰。这保证了即使目标系统处于“中止”状态，远程调试器发出的 Resume 命令仍能通过 CAN 接口被接收和处理，从而允许 VDP 退出驻留循环，恢复应用程序执行。
- 影响范围： 只有优先级高于 DBGMON 的中断才能继续执行。所有优先级低于 DBGMON 的任务和中断都将被阻塞，其延迟将显著增加，这体现了实时性与调试深度之间的折衷。
这种优先级分离策略是 Monitor Mode Debugging 的核心价值所在：它允许设计者牺牲低优先级任务的实时性，以保护高优先级、对时间敏感的通信或安全任务的连续性¹¹。
IV. DBGMON中断处理程序（ISR）的实现细节与编程要点
4.1 DBGMON异常的优先级配置与策略
DebugMonitor 异常的优先级是可配置的。在设计 VDP 固件时，通常建议遵循“最低优先级原则”¹¹。
- 目标： 将 DebugMonitor 异常配置为所有可编程异常中的最低优先级（即优先级寄存器中的最大数值）。例如，如果 NVIC 支持 16 级优先级（0-15），DBGMON 应该设置为 15。
- 目的： 这样做可以最大化其他所有中断和系统异常（如 PendSV 用于 RTOS 任务切换、SysTick 用于定时）在调试期间的执行机会。只有那些对实时性要求最低的应用程序代码会被 DBGMON 循环阻塞¹¹。
- 限制： DBGMON被配置为最低优先级，则调试只能观察非中断情况的应用程序执行，对于高优先级的中断，因为无法立即触发重入DBGMON中断而无法执行类似断点或者STEP的调试操作。如果需要对一些中断进行调试则应配置DBGMON中断优先级高于被调试中断优先级。
层级总结： 理想的优先级层级应为：
- 固定最高优先级： Reset, NMI, HardFault⁵。
- 关键实时优先级： CAN ISR、安全监控 ISR（数值低）。
- 系统调度优先级： PendSV, SysTick (数值中等)。
- 调试优先级： DebugMonitor (数值最高，例如 15)。
4.2 DebugMon_Handler 的实现要求：使用 naked 属性
DebugMonitor 中断服务程序 DebugMon_Handler 的实现必须极为谨慎，通常要求使用汇编语言或 C 语言的 __attribute__((naked)) 属性¹²。
为什么需要 naked：
标准的 C 语言 ISR 函数，编译器会自动生成序言（prologue）和尾声（epilogue）代码，用于保存和恢复当前 ISR 自身的上下文。然而，在调试场景中，目标是向外部调试器显示被中断的应用线程的上下文状态（寄存器、PC、堆栈）¹⁰。如果使用标准 ISR，调试器将错误地看到 DebugMon_Handler 的上下文，导致调用栈和变量信息错误。
手动上下文控制：
使用 naked 属性告知编译器，该函数体将完全由开发人员通过内联汇编或外部汇编实现¹²。VDP 固件必须：
- 保存额外寄存器： 异常入口时，硬件只自动保存部分核心寄存器到堆栈。VDP 必须手动保存其余未自动压栈的寄存器。
- 修正堆栈指针： 计算当前堆栈指针（SP）的位置，并精确解析硬件压栈帧。
- 状态传递： 将修正后的 SP 和寄存器组传递给 VDP 的高级 C 语言处理逻辑。
- 恢复与返回： VDP 逻辑完成后（例如，收到 Resume 命令），手动恢复所有寄存器，并执行 BX LR 指令安全退出异常。
这种手动控制堆栈帧的能力是 VDP 能够成功模拟调试探针并正确显示应用上下文的关键¹⁰。
4.3 驻留循环与调试状态维持
如前所述，当目标被“中止”时，实际上是核心进入了 DebugMon_Handler 内部的一个驻留循环¹⁰。
驻留循环的作用：
该循环阻止核心返回到应用程序代码。在循环内部，VDP 固件的核心任务是服务远程调试器发来的请求（通过高优先级的 CAN ISR 接收到的数据），例如内存/寄存器读取和修改。
退出条件：
只有当 VDP 收到 Resume 命令后，它才会执行以下关键操作：
- 清除 DEMCR.MON_STEP (如果之前处于单步模式) 和 DEMCR.MON_PEND。
- 恢复应用程序的完整上下文（包括 PC、SP 等）。
- 执行异常返回，将控制权精确交还给被中断的应用程序代码，从而实现无缝的非中止式恢复执行¹⁰。
V. 应用限制、风险与架构特定考量
5.1 Cortex-M33 TrustZone (Armv8-M) 的特殊要求与隔离
对于基于 Armv8-M 架构的 Cortex-M33 处理器，DebugMonitor 的实现必须考虑 Arm TrustZone 技术带来的安全扩展和隔离¹³。TrustZone 将系统划分为 Secure (S) 安全状态和 Non-secure (NS) 非安全状态。
异常目标分离：
在 M33 架构中，DBGMON 异常是安全状态感知的。一个调试事件会根据其发生的上下文（S 或 NS）以及异常目标状态，指向不同的向量表和不同的 DBGMON Handler（Secure DebugMonitor Handler 或 Non-secure DebugMonitor Handler）⁷。Secure HardFault 具有极高优先级，甚至可以抢占 Non-secure NMI⁷。
跨域调试的挑战：
如果 VDP 固件仅运行在 Non-secure 状态，它对 Secure 域的调试能力将受到严格限制。TrustZone 通过内存保护单元（MPU）和其它机制，限制 NS 软件访问 S 域的内存和寄存器¹³。
要实现对整个系统（包括 Secure 固件）的全面调试，VDP 必须具备“双状态感知”能力。这意味着 VDP 必须能够：
- 检测当前被中断的上下文是 S 还是 NS。
- 安全地从 Non-secure 状态请求 Secure Monitor Service，以访问或修改 Secure 域的调试信息¹⁴。
- Secure DBGMON Handler 必须是唯一或至少是主要的 S 域调试入口⁷。
这种对 Armv8-M 安全扩展的依赖，使得 Cortex-M33 平台上的 VDP 实施比 M7 架构复杂得多，要求开发者具备深入的 TrustZone 架构知识，以避免因权限不足而触发 SecureFault 或 HardFault。
5.2 低功耗模式与可调试性的矛盾
DebugMonitor 机制依赖于 CPU 核心和关键外设（如 CAN 接口）在进入 DBGMON 异常时保持活跃。这与追求极低功耗的系统设计目标直接冲突。
SRAM 存活性要求：
许多微控制器在深度低功耗模式下，会关闭或限制 SRAM 供电以大幅降低静态功耗。由于 VDP 固件需要 SRAM 来存储调试上下文、堆栈帧和通信缓冲区，一旦 SRAM 被禁用，VDP 调试机制将完全失效，在云途MCU中，SRAM在PowerDown模式仅有一部分内容可以保留，不过这个本身并不影响VDP固件，因为PowerDown模式的唤醒本身也是需要复位过程的。针对STANDBY模式，SRAM的内容都是可以保留的，只需要VDP固件可以支持唤醒对应的低功耗模式即可，例如基于CAN的VDP固件，可以直接用CAN的报文唤醒。
唤醒竞争与时钟速率：
在设计低功耗系统时，调试器试图通过 DAP 触发 DBGMON 异常来唤醒核心，可能与系统本身的定时器或外部唤醒源产生竞争。有实践表明，当调试时钟速率较高或系统处于较长的唤醒间隔时，DBGMON 异常可能被不稳定地触发，这要求在低功耗应用中，必须将调试时钟速率和功耗模式进行精细的权衡。
设计折衷：
为了支持 VDP 远程调试，系统必须维持在一个能够响应中断并保持关键 SRAM 活跃的“浅层”睡眠状态（例如 Wait-for-Interrupt 模式），这必然会提高系统的基础静态电流消耗。开发者在集成 VDP 时，必须明确地在调试便利性和最终产品的功耗指标之间做出折衷。当然也可以配置为VDP仅支持运行模式的调试。
5.3 故障与异常处理的机制
DebugMonitor 机制对于系统稳定性至关重要，但配置或使用不当会引发严重故障：
- 配置错误引发 HardFault： 如第 II.2.1 节所述，如果 Halting Debug 和 DBGMON 都被禁用，断点事件将升级为 HardFault¹。这是 VDP 实施中必须严格规避的风险点。
- 高优先级异常抢占： 尽管 DBGMON 优先级通常被设置为最低，但它仍有可能被 NMI 或 HardFault 等更高优先级的异常抢占⁵。如果发生这种情况，调试会话会暂停，VDP 必须设计机制来检测和处理这些高优先级异常的返回，才能安全地恢复对目标系统的控制权。在抢占期间，VDP 无法执行调试命令。
VI. 结论与最佳实践建议
6.1 总结DBGMON在复杂嵌入式系统中的核心价值
DebugMonitor 异常是 ARM Cortex-M7/M33 架构提供的关键功能，实现了高实时性、非侵入式调试。通过将传统的硬中止转换为可配置的系统异常，DBGMON 允许时间敏感型任务（如 CAN-FD 通信）在核心进行调试操作时保持连续执行。结合可靠的通信链路，DebugMonitor 支撑了远程、软件驱动的虚拟调试探针（VDP）的实施，极大地拓宽了复杂嵌入式系统的调试范围和效率。
6.2 最佳实践与实施指南
基于对 DebugMonitor 机制的深入分析，实施 VDP 固件时应遵循以下专业指南：
- 优先级分离的刚性原则： 必须将所有关键的实时 ISR 配置为比 DebugMonitor ISR 更高的优先级（数值更低）。同时，将 DBGMON 设置为可编程的最低优先级（最高数值），以最大限度地减少对系统调度的影响¹⁰。
- 强制性使用 naked Handler： DebugMon_Handler 必须使用
__attribute__((naked))属性，并完全通过汇编代码手动处理上下文保存、堆栈指针修正和寄存器恢复，以确保调试器看到的是正确的应用程序上下文¹⁰。 - 模式初始化检查： 在系统启动 VDP 固件之前，必须以原子操作检查并配置 DHCSR.C_DEBUGEN = 0 和 DEMCR.MON_EN = 1，以确保进入 Monitor Mode Debugging，防止调试事件意外升级为 HardFault¹。
- Armv8-M TrustZone 兼容性： 对于 Cortex-M33 平台，如果需要调试 Secure 状态的代码，VDP 固件必须设计为安全状态感知，并利用 Secure Monitor Handler 作为 Secure 域的调试入口，以遵守 TrustZone 的安全隔离规则¹⁴。
- 低功耗模式的明确限制： 如果系统需要支持 VDP 远程调试，必须接受牺牲深度低功耗模式。系统必须保持在 SRAM 和关键通信外设活跃的浅层睡眠状态，以保证 VDP 能够及时响应远程调试命令。
表格 I：DEMCR (Debug Exception and Monitor Control Register) 关键位域功能表
| 位域 | 名称 | 描述 | 配置用途 |
|---|---|---|---|
| MON_EN | Monitor Enable | 启用 DebugMonitor 异常。与 DHCSR.C_DEBUGEN 互斥⁸ | |
| MON_PEND | Monitor Pending | 调试器强制设置，用于软件触发 DBGMON 异常⁸ | |
| MON_STEP | Monitor Step | 使能单步调试。从 DBGMON 返回后执行单步并再次触发 DBGMON⁸ |
表格 II：DebugMonitor 与 Halting Debug 模式对比
| 特性 | Halting Debug (传统) | Monitor Mode Debug (DBGMON) | 核心区别 |
|---|---|---|---|
| CPU状态 | 完全中止（Halt State） | 核心在执行 DBGMON ISR 的驻留循环³ | |
| 实时性影响 | 严重，所有中断被阻塞 | 仅阻塞优先级低于 DBGMON 的中断¹⁰ | 中断连续性 |
| 控制寄存器 | DHCSR | DEMCR | 软件/硬件控制点¹⁰ |
| 单步机制 | 高度确定性 | 依赖 MON_STEP 循环，可能被低优先级异常入口抢占⁹ | 确定性 |
| 故障处理 | 调试事件直接中止 | 禁用时调试事件可能升级为 HardFault¹ | 安全机制 |
Works cited
- Debug event behavior - Arm Developer, accessed October 5, 2025, https://developer.arm.com/documentation/ddi0403/d/Debug-Architecture/ARMv7-M-Debug/Debug-event-behavior
- Cortex-M Debug Monitor - Zephyr Project Documentation, accessed October 5, 2025, https://docs.zephyrproject.org/latest/services/debugging/debugmon.html
- Monitor Mode Debugging - Revolutionize the way you debug BLE applications, accessed October 5, 2025, https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/monitor-mode-debugging---revolutionize-the-way-you-debug-ble-applications
- ARM® Cortex®-M for Beginners, accessed October 5, 2025, https://community.arm.com/cfs-file/__key/telligent-evolution-components-attachments/01-2142-00-00-00-00-52-96/White-Paper-_2D00_-Cortex_2D00_M-for-Beginners-_2D00_-2016-_2800_final-v3_2900_.pdf
- Exception priority level definitions - Arm Developer, accessed October 5, 2025, https://developer.arm.com/documentation/107706/latest/Exceptions-and-interrupts-overview/Exception-priority-level-definitions
- About debug events - Arm Developer, accessed October 5, 2025, https://developer.arm.com/documentation/ddi0406/c/Debug-Architecture/Debug-Events/About-debug-events
- Exception types - Arm Cortex-M85 Processor Devices Generic User Guide, accessed October 5, 2025, https://developer.arm.com/documentation/101928/0101/The-Cortex-M85-Processor--Reference-Material/Exception-model/Exception-types
- Debug Exception and Monitor Control Register, DEMCR - Arm Developer, accessed October 5, 2025, https://developer.arm.com/documentation/ddi0403/d/Debug-Architecture/ARMv7-M-Debug/Debug-register-support-in-the-SCS/Debug-Exception-and-Monitor-Control-Register--DEMCR?lang=en
- Halting debug stepping - ARMv7-M Architecture Reference Manual, accessed October 5, 2025, https://developer.arm.com/documentation/ddi0403/d/Debug-Architecture/ARMv7-M-Debug/Debug-event-behavior/Debug-stepping
- Using CAN FD for Remote Hardware Debugging of Cortex-M Devices | MCU on Eclipse, accessed October 5, 2025, https://mcuoneclipse.com/2025/09/25/using-can-fd-for-remote-hardware-debugging-of-cortex-m-devices/
- Cortex-M Debug Monitor - Technical Documentation, accessed October 5, 2025, https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/services/debugging/debugmon.html
- attribute__((naked)) function attribute - Arm Compiler armclang Reference Guide, accessed October 5, 2025, https://developer.arm.com/documentation/dui0774/latest/Compiler-specific-Function--Variable--and-Type-Attributes/--attribute----naked---function-attribute
- Arm Cortex-M33 Processor Datasheet, accessed October 5, 2025, https://www.arm.com/-/media/Arm%20Developer%20Community/PDF/Processor%20Datasheets/Arm-Cortex-M33-Processor-Datasheet.pdf
- TrustZone technology for the ARMv8-M architecture Version 2.0 - Arm Developer, accessed October 5, 2025, https://developer.arm.com/documentation/100690/0200/ARM-TrustZone-technology
- Arm Cortex-M33 Devices Generic User Guide r0p3, accessed October 5, 2025, https://developer.arm.com/documentation/100235/0003/the-cortex-m33-processor/exception-model/exception-types
- Debug Halting Control and Status Register, DHCSR - Arm Developer, accessed October 6, 2025, https://developer.arm.com/documentation/ddi0403/d/Debug-Architecture/ARMv7-M-Debug/Debug-register-support-in-the-SCS/Debug-Halting-Control-and-Status-Register--DHCSR?lang=en
最后更新于 2025-10-07 06:58:52 并被添加「MCU 嵌入式」标签，已有 280 位童鞋阅读过。
本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。