C1 ARMv7-M Debug

Different

ARMv7-M 支持 Debug Monitor 调试监控异常、暂停调试和相关的调试状态，ARMv6-M 仅支持暂停调试，且仅在存在调试扩展时才支持。
ARMv7-M 中的调试资源通常可从处理器或使用调试访问端口 (DAP) 进行访问。ARMv6-M 仅要求使用 DAP 访问调试资源。
与 ARMv7-M 相比，ARMv6-M 提供的调试功能更简单，选项更少：

• 调试仅由可选的调试扩展提供。
• 仅支持暂停调试。ARMv6-M 不提供调试监控异常。
• ARMv6-M 提供
  • 使用 BKPT 指令支持软件断点
  • 使用断点单元 (BPU) 支持硬件断点

​ 注意：BPU 与 ARMv7-M 中的 Flash 碎片与断点单元 (FPB) 相对应。

• 观察点支持仅提供数据访问地址匹配。ARMv6-M 不支持数据值观察点。
• ARMv6-M 提供了一个可选的 PC 采样寄存器 PCSR。它不提供任何其他周期计数器或 DWT 跟踪支持。
• ARMv6-M 不支持
  • 指令跟踪宏单元 (ITM)
  • 嵌入式跟踪宏单元 (ETM) 或相关的跟踪端口接口单元 (TPIU)。

C.1.4 ARMv6-M 中的调试和复位
ARM 建议包含调试扩展的实施为上电复位和本地复位实施单独的复位域。但是，实际复位方案由实施定义。有关详细信息，请参见第 C1-323 页上的调试和复位。

C1.1 Introduction to ARMv7-M debug

本节描述 ARMv7-M 架构配置文件中的调试体系结构。包括仅在 M 系列配置文件中支持的几个调试特性。

调试支持是 ARM 架构的一个关键元素。ARMv7-M支持一系列侵入式和非侵入式调试机制。

侵入式调试机制:

• 能够暂停处理器，例如在断点处。该方式提供了一个“运行-停止”调试模型。
• 调试代码使用 DebugMonitor 异常。该方式提供了比暂停处理器更少侵入性的调试。

非侵入式调试技术:

• 通过写入指令跟踪宏单元 (Instrumentation Trace Macrocell，ITM)进行应用程序跟踪，产生非常低等级的侵入。
• 非侵入式程序跟踪和分析。

调试软件通常使用 DAP 访问处理器的调试功能，参见C1-682页上的调试访问端口。这提供了对处理器运行、暂停或保持复位时对调试资源的访问。当处理器被暂停时，则它处于调试状态。当处理器没有暂停时，它处于非调试状态。

ARMv7-M 调试架构支持以下特性:

• 使用 ITM 进行高等级跟踪。
• 分析各种包括相关时序信息的系统事件。这可以包括监视与中断和睡眠功能相关的处理器时钟计数。
• PC采样和事件计数相关的加载和存储操作、指令折叠、基于单指令周期 (CPI)计数的性能统计。
• 数据跟踪。
• 指令跟踪，使用嵌入式跟踪宏单元 (Embedded Trace Macrocell，ETM)。

在ARMv7-M系统地址映射中，调试资源位于私有外设总线(Private Peripheral Bus，PPB)区域。除系统控制空间(System Control Space，SCS)中的资源外，其他每个调试组件占用固定的 4KB 地址区域。
这些调试资源包括：

• 支持 DAP 和暂停调试。
• 不支持 ITM。（注意：当 ITM 功能被禁用或不存在时，对 ITM 激励端口的写入不得导致总线故障异常。这可确保该功能对应用代码透明，请参阅第 C1-705 页上的 ITM 操作。）
• FPB 支持两个断点，不支持重新映射。
• DWT 支持一个观察点，不支持跟踪、周期计数器和外部匹配信号，CMPMATCH[N]。
• 调试监视器（Debug monitor）支持最低级别的调试功能，包括列出的 FPB 和 DWT 事件。

全面的调试支持要求:

• 支持 DebugMonitor 异常和暂停调试。
• 实现 ITM 单元，支持至少 8 个激励端口寄存器。
• 实现 DWT 单元，支持:
  — 至少 1 个观察点。
  — 所有 DWT 跟踪功能。
  — 周期计数。
  — 分析计数器。
  如果实现包含 ETM，则 DWT 单元必须支持 CMPMATCH[N]，否则是否支持此信令由实施定义（ IMPLEMENTATION DEFINED）。
• 实现至少支持 2 个断点的 FPB 单元。

C1.2 The Debug Access Port

调试访问端口（DAP）是 ARM调试接口v5架构规范（ADIv5）的实现，可访问 ARMv7-M 实现的调试功能访问。

有关DAP的更多信息，请参阅 《ARM调试接口v5架构规范（ARM Debug Interface v5 Architecture Specification）》。

警告

在软件执行过程中，通过 DAP 的访问可更改系统控制和配置字段，特别是 SCB 中的寄存器。例如，DAP 访问可能会修改用于动态更新的资源。如果应用程序和调试器都更新相同或相关的资源，这可能会产生不良的副作用。对于通过 DAP 更新运行系统的后果，体系结构无法提供任何保证，而且此类更新对系统行为的影响可能会比不可预测更严重。ARM 强烈建议在软件运行时，调试器一般不要执行 MPU 或 FPB 地址重映射，以避免可能出现的上下文问题。

C1.2.1 General rules applying to debug register access

标题：应用于调试寄存器访问的一般规则

私有外设总线(PPB)，地址范围为 0xE0000000 ~ 0xE0100000，支持以下一般规则:

• 该区域定义为强序内存，参见 A3-83 页的强序内存和 A3-84 页的内存访问限制。
• 寄存器始终以小端码方式访问，与处理器的端码状态无关。
• 调试寄存器只能以字访问方式访问。字节和半字访问是不可预知的。
• 保留的寄存器或位字段值为 UNK/SBZP（读写时返回值未知/写总是0）

除非另有说明，否则无权访问 PPB 会导致总线故障错误。例外情况包括：

• 软件可将配置控制寄存器中的一位设置为 1，以启用对软件触发中断寄存器的非授权访问。
• 无权限访问 ITM 的行为。更多信息，请参阅第 C1-705 页上的 ITM 操作。

C1.2.2 The ARMv7-M ROM Table

ARMv7-M 系统包含一个 ROM 表，该表显示已实施的调试组件以及这些组件在内存映射中的位置。有关 ROM 表项的格式，请参阅《ARM 调试接口 v5 架构规范》*。

表 C1-3 显示了 ROM 表的格式。
对于 ARMv7-M ROM 表，所有地址偏移均为负数。条目 0x00000000 是表结束标记。

(a). 访问不能导致不存在的内存异常。
(b). 共享资源是由本地处理器管理还是由其他资源管理，由实施情况（IMPLEMENTATION DEFINED）决定。

调试器可使用 DAP 接口查询系统的内存访问端口（MEM-APs）。内存访问端口的基寄存器提供 ROM 表的地址，或 ROM 表层次结构中一系列 ROM 表的第一个地址。内存访问端口可用于获取 ROM 表项。更多信息，请参见 《ARM 调试接口 v5 架构规范》。

C1.3 ARMv7-M debug features

标题：ARMv7-M 调试特性

ARMv7-M 定义了专为该配置文件设计的调试模式。ARMv7-M 调试模型在内存映射中集成了控制和配置功能。《ARM 调试接口 v5 架构规范》中定义的调试访问端口（DAP）为主机调试器提供了接口。ARMv7-M 中的调试资源如第 C1-679 页表 C1-1 所示。

ARMv7-M 支持以下调试相关功能：

• 本地复位，请参阅第 B1-519 页上的支持的异常概述。这将复位处理器并支持复位事件的调试。
• 处理器暂停。控制寄存器支持暂停处理器。这可以通过断言外部信号、执行 BKPT 指令或调试事件异步发生。调试器可以配置调试事件，例如在复位、退出或进入 ISR 时发生。
• 单步，带或不带中断屏蔽。
• 运行，带或不带中断屏蔽。
• 寄存器访问。DCB 支持在软件执行暂停时读写内核寄存器。
• 通过 SCS 资源访问与异常相关的信息。例如，当前正在执行的异常（如果有）、活动列表、挂起列表和优先级最高的待处理异常。
• 软件断点。支持 BKPT 指令。
• 硬件断点、硬件观察点，并支持代码内存位置的重映射。
• 通过 DAP 访问所有内存。
• 支持分析。支持 PC 采样。
• 支持指令跟踪，并能添加其他系统调试功能，如总线监控器，或交叉触发设施。使用 ETM 指令跟踪会增加所需的跟踪带宽，支持 ETM 指令跟踪的实现通常使用带有并行跟踪端口输出的 TPIU。
• 应用和数据跟踪，通常通过引脚数少的串行线路查看器（SWV）或并行跟踪端口来支持。

注意：ARMv7-M 不要求服从 CoreSight 架构。本规范中 DWT、ITM、TPIU 和 FPB 单元的寄存器定义和地址空间分配是兼容的。ARMv7-M 通过使用 CoreSight ID 和管理寄存器对这些单元进行扩展，使其能够酌情添加对 CoreSight 拓扑检测和操作的支持。

C1.3.1 Debug authentication

标题：调试身份验证

本手册使用 CoreSight 架构信号 DBGEN 和 NIDEN 来描述 IMPLEMENTATION DEFINED 身份验证接口。如果处理器处于调试状态，则处理器的行为与 DBGEN 被断言时一样。

DBGEN被认为永久启用（即DBGEN = 高电平）时，将控制延迟到配置文件特定调试架构中的其他使能位是可以接受的。

有两种暂停调试身份验证模式：

表 C1-4 暂停调试身份验证

当 DHCSR.C_DEBUGEN 被清 0，或处理器处于禁止暂停状态时，处理器不得进入调试状态。

有两种非侵入式调试验证模式：

表 C1-1 非侵入式调试身份验证

DebugMonitor Authentication

标题：调试监控器身份验证

当 DEMCR.MON_PEND 置 1 时，处理器将根据异常优先级模型处理 DebugMonitor 异常。无论 DEMCR.MON_EN 和 IMPLEMENTATION DEFINED 身份验证接口的值如何，处理器都将处理 DebugMonitor 异常。

对 DEMCR 的直接写入可随时将 DEMCR.MON_PEND 置 1，使调试监控异常挂起；也可将 DEMCR.MON_PEND 清零，删除挂起的调试监控异常。
当设置为 1 时，DEMCR.MON_PEND 将保持设置为 1，直到 DebugMonitor 异常被消除或写入将该字段清除为 0。

如果 DebugMonitor 组优先级大于当前执行优先级，且 DEMCR.MON_EN 置 1，则外部调试请求（受 EDBGRQ 信号控制）不会生成调试状态入口，会将 DEMCR.MON_PEND 设置为 1。

DAP access permissions

标题：DAP 访问权限

当断言 DBGEN 或 DHCSR.S_HALT == 1（表示启用所有调试）时，DAP 可以访问所有内存。第 C1-686 页的表 C1-6 和表 C1-7 显示了禁用外部调试或仅启用非侵入式调试时的访问权限。

注意 CoreSight 接入端口（AP）也有一个 DEVICEEN端口，当该断言为低，将禁止 AP 的所有访问。实施DEVICEEN端口可提供另一级访问控制。

表 C1-6 显示了 DBGEN 失效和 DHCSR.S_HALT == 0 时的 DAP 访问权限。

表 C1-6 DBGEN 失效时的 DAP PPB 访问权限

表 C1-7 显示了 DBGEN 失效和 DHCSR.S_HALT == 0 时的 DAP PPB 访问权限。

表 C1-7 DBGEN 失效时的 DAP PPB 访问权限

(a). 为每个调试组件执行 CoreSight 软件锁定寄存器。这些寄存器是可选的。
(b). 每个执行 CoreSight ID 寄存器的调试组件。这些寄存器为可选寄存器。

访问受阻会向 DAP 返回错误响应。

Debug functions

标题：调试功能

下面几节描述调试功能。

SCS (System Control Space)

当 DGBEN 为低且 DHCSR.S_HALT == 0 时：
• 不会进入调试状态。
• DHCSR.{C-HALT、C_STEP、C_MASKINTS、C_SNAPSTALL}不起作用，处理器的行为如同这些位为零。
• DEMCR.VC_* 位被忽略。
• EDBGRQ不会产生调试状态入口，如果没有产生 DebugMonitor 异常，则会被忽略。
• BKPT 指令不会生成调试状态入口，如果没有生成 DebugMonitor 异常，则会升级到 HardFault 或锁定。
• FPB 断点不会进入调试状态，如果没有产生 DebugMonitor 异常，则会升级到 HardFault、锁定或被忽略。请参阅第 C1-690 页上的 调试事件行为。
• DWT 监视点不会生成调试状态条目，如果未生成 DebugMonitor 异常，则会被忽略。

注意：在 HardFault 或锁定之间的选择由当前优先级决定。请参阅第 B1-510 页上的 优先级、执行优先级、异常输入和执行抢占。

当 DBGEN 为低、DHCSR.S_HALT == 0 和 NIDEN 为低时，处理器也必须按照 DEMCR.TRCENA == 0 的方式运行。

DWT (Debug Watchpoint and Trace)

DWT 支持侵入式和非侵入式调试功能。
当 DBGEN 为低且 DHCSR.S_HALT == 0 时，处理器和系统必须保证 CMPMATCH 事件（如果支持）不影响处理器的执行。

注意：CMPMATCH 可能与 ETM 连接，并用于断言 EDBGRQ，但处理器会忽略这一点。

当 DBGEN 为低、DHCSR.S_HALT == 0 且 NIDEN 为低时，必须禁用 DWT。DWT_PCSR 的读数将返回 "0xFFFFFFFF"，计数器不计数。

ITM (Instrumentation Trace Macrocell)

当 DBGEN 为低、DHCSR.S_HALT == 0 且 NIDEN 为低时，必须禁用 ITM。

ETM (Embedded Trace Macrocell)

DBGEN 为低、DHCSR.S_HALT == 0 且 NIDEN 为低时，必须禁用 ETM。

C1.3.2 Multiprocessor support

标题：多核处理器支持

支持一个以上处理器调试的系统要求每个 ARMv7-M 处理器都支持：
• 外部调试请求。
• 交叉调试事件。
• 外部重启请求。
这些可实现处理器之间调试事件的交叉触发。这些事件可连接到嵌入式交叉触发器 (ECT)，如 CoreSight 交叉触发接口 (CTI)。

注意：
多个处理器可以是单个设备中的处理器，也可以是更复杂系统中的异构处理器，例如为以下设备提供调试支持的集成系统：
• 多个 ARMv7-M 处理器。
• 一个 ARMv7-M 处理器和一个 ARMv7-A 处理器。
• 一个 ARMv7-M 处理器和一个 DSP。

在其他系统中，对这些功能的支持是可选的。

External debug request

标题：外部调试请求

当处理器处于非调试状态时，外部代理可发出外部调试请求信号。外部调试请求可导致调试事件，调试事件包括
• 进入调试状态。
• DebugMonitor 异常。
更多信息，请参阅第 C1-690 页上的 调试事件行为。DFSR.EXTERNAL 状态位指示调试事件，请参见 调试故障状态寄存器，DFSR（第 C1-695 页）。
当处理器处于调试状态时，会忽略外部调试请求。
在有多个处理器的系统中，需要支持外部调试请求，以便在处理器之间交叉触发调试事件。
在其他系统中，对外部调试请求的支持是可选的。

注意
外部调试请求如何向处理器发出信号是由实施情况决定的，但可能包括以下内容：
• 外部代理向处理器发出 EDBGRQ 输入信号。
• 作为 ECT（如 CoreSight CTI）的触发输出。

Cross-halt event

标题：交叉暂停事件

当处理器进入调试状态时，它会向外部代理发出进入调试状态的信号。
在有多个处理器的系统中，需要支持交叉暂停事件，以便在处理器之间交叉触发调试事件。
在其他系统中，对交叉调试事件的支持是可选的。

注意
交叉暂停事件如何向外部代理发出信号是由实施情况决定的，但可能包括以下内容：
• 处理器向处理器断言一个 HALTED 输出，该输出反映 DHCSR.S_HALT 位，请参阅第 C1-696 页上的 调试停顿控制和状态寄存器，DHCSR。
• 作为 ECT（如 CoreSight CTI）的触发输入。

External restart request

标题：外部重启请求

当处理器处于调试状态时，外部代理可以发出外部重启请求信号，使处理器退出调试状态。
当处理器处于非调试状态时，它会忽略外部重启请求。
在有多个处理器的系统中，需要支持外部重启请求，以便在处理器之间交叉触发调试事件。
在其他系统中，对外部重启请求的支持是可选的。

注意
外部重启请求如何向处理器发出信号是由实施情况决定的，但可能包括以下内容：
• 外部代理向处理器发出DBGRESTART输入信号。
• 作为 ECT（如 CoreSight CTI）的触发输出。

C1.4 Debug and reset

标题：调试和复位

ARMv7

ARMv7-M 定义了两种级别的复位，如第 B1-519 页上的 "支持的异常概述"所述：
• 上电复位。
• 本地复位。

第 B1-555 页上的复位管理描述了软件如何启动复位。C1.4.1 离开复位状态时进入调试状态 介绍软件如何配置处理器在复位后进入调试状态。

某些控制字段在上电复位时复位，但在本地复位时保持不变。详情请参见寄存器说明。

本地复位将使处理器退出调试状态。

注意：
ARMv7-M 不提供以下方法：
• 调试上电复位。
• 区分上电复位和本地复位。

与 《ARM 调试接口 v5 架构规范》中描述的调试逻辑复位和电源控制信号之间的关系由实施定义。

C1.4.1 Entering Debug state on leaving reset state

标题：离开复位状态时进入调试状态

为了强制处理器在复位后立即进入调试状态，调试器将 DHCSR.C_DEBUGEN 置 1 以启用 "暂停调试"，并将 DEMCR.VC_CORERESET 置 1 以启用复位异常的向量捕获。当处理器从复位中出来时，它将 DHCSR.C_HALT 置1，并进入调试状态。更多信息，请参阅第 C1-696 页上的 调试停止控制和状态寄存器 DHCSR 和第 C1-702 页上的 调试异常和监控控制寄存器 DEMCR。

ARMv6

ARMv6-M 定义了两种级别的复位，如第 B1-218 页的 "支持的异常概述 "中所述：

• 上电复位。
• 本地复位。

通常情况下，在 ARMv6-M 实施中：

• 上电复位同时适用于处理器和调试组件
• 本地复位仅适用于处理器，不适用于调试组件。

但是，ARMv6-M 架构只要求开机复位包括本地复位。实际复位方案由实施定义。

注意

• ARM 建议 ARMv6-M 实现包括用于上电复位和本地复位的单独复位域。
• ARMv6-M 不提供任何方法来
  • 调试上电复位。
  • 区分上电复位和本地复位。

软件可以启动系统复位，如第 B1-240 页的复位管理中所述。软件可以使用复位向量捕获控制位 DEMCR.VC_CORERESET，在处理器复位时生成调试事件。当 DHCSR.C_DEBUGEN == 1（表示已启用停止调试）时，调试事件会导致处理器暂停，进入调试状态。
上电复位会复位下列位字段，但本地复位不会：

• DFSR 中的故障标志，请参见第 C1-330 页上的调试故障状态寄存器 DFSR
• DHCSR 中的调试控制，请参见第 C1-331 页上的调试停止控制和状态寄存器 DHCSR 的相关说明
• 向量捕获配置位，请参见第 C1-338 页的调试异常和监控控制寄存器 DEMCR。

有关复位和 DWT，请参见第 C1-345 页上的 DWT 寄存器摘要。关于复位和 BPU，请参见第 C1-352 页的 BPU 寄存器摘要。
与 DAP 中调试逻辑复位和电源控制信号的关系由实施定义。更多信息，请参见 《ARM 调试接口 v5 架构规范》。

C1.5 Debug event behavior

标题：调试事件行为

因调试原因触发的事件称为调试事件。调试事件会导致以下情况之一发生：
• 进入调试状态。如果启用了 "暂停调试"，调试事件将使处理器暂停在调试状态。
将 DHCSR.C_DEBUGEN 位置 1 可启用 "暂停调试"，请参阅第 C1-696 页上的 调试停止控制和状态寄存器，DHCSR。
导致进入调试状态的调试事件会将 DHCSR.C_HALT 置 1。
• DebugMonitor 异常。如果禁用了 "暂停调试" 并启用了 DebugMonitor 异常，则当 DebugMonitor 异常的组优先级大于当前执行优先级时，调试事件会导致 DebugMonitor 异常。
当 DHCSR.C_DEBUGEN 位置 0，或通过禁用调试身份验证接口时，将禁用 "暂停调试"，请参见 调试停止控制和状态寄存器 DHCSR （第 C1-696 页）和 调试验证 （第 C1-684 页）；当 DEMCR.MON_EN 置 1 时，将启用 DebugMonitor 异常，请参见 调试异常和监控控制寄存器 DEMCR （第 C1-702 页）。
如果 DebugMonitor 组优先级小于或等于当前执行优先级：
• 处理器会将执行 BKPT 指令产生的断点调试事件升级为 HardFault 硬故障。
• 处理器是将 FPB 生成的断点升级为 HardFault，还是忽略 FPB 断点，由 IMPLEMENTATION DEFINED 决定。但是，只有当断点所针对的指令显示为其架构行为时，处理器才能忽略 FPB 断点。
• 处理器会忽略其他调试事件。这意味着它会忽略观察点和外部调试请求。
产生 DebugMonitor 异常的调试事件会将 DEMCR.MON_PEND 设为 1。

注意：软件可随时将 DEMCR.MON_PEND 设为 1，使 DebugMonitor 异常等待处理。当 DEMCR.MON_PEND 设置为 1 时，处理器将根据异常优先级规则处理 DebugMonitor 异常，而与 DEMCR.MON_EN 位的值无关。

• HardFault 硬故障异常。如果同时禁用 "暂停调试 "和 "监视器"，则断点调试事件将升级为 "硬故障"，处理器将忽略其他调试事件。
• 如果在“暂停调试”被禁用时，NMI 或 HardFault 异常处理程序中出现断点，系统就会锁定并出现无法恢复的错误。有关详细信息，请参阅第 B1-551 页上的 无法恢复的异常情况。断点可由 BKPT 指令或 FPB 生成，请参阅第 C1-751 页上的 闪存补丁和断点单元。

注意
• 当 DHCSR.C_DEBUGEN 设置为 0 和 DEMCR.MON_EN 设置为 0 时，FPB 是否生成断点调试事件由实施定义。
• 导致 HardFault 或锁定的断点调试事件被视为不可恢复。

执行的 BKPT 指令会触发 HardFault 和锁定实例的原因是，当处理器没有执行如下：
• 设置 DHCSR.C_HALT，因为暂停被禁止。
• 设置 DEMCR.MON_PEND，因为禁用了 DebugMonitor 或处理器的执行优先级低于 DebugMonitor。

DFSR 包含每个调试事件的状态位，请参阅第 C1-695 页上的 调试故障状态寄存器，DFSR。当调试事件导致处理器暂停或产生异常时，这些位将被置 1，然后写1清除。当事件被忽略或导致锁定时，是否更新这些位由实施定义。

调试事件如表C1-8所示。

表 C1-8 调试事件

有关向量捕获功能的说明，请参阅第 C1-693 页的向量捕捉。

C1.5.1 Debug stepping

标题：调试步进

ARMv7-M 支持在 "暂停调试 "和 "监视器调试 "中进行步进调试，请参阅以下内容：
• 暂停调试步进.
• 监视器调试步进（第 C1-692 页）。

Halting debug stepping

标题：暂停调试步进

调试器可以使用 "暂停调试步进 "从调试状态退出，执行单个指令，然后再次进入调试状态。当符合以下所有条件时，"暂停调试步进" 处于活动状态：
• DHCSR.C_DEBUGEN 置 1，启用 "暂停调试"，请参阅第 C1-696 页上的 调试停止控制和状态寄存器，DHCSR。
• DHCSR.C_STEP 置 1，启用 "暂停步进"。
• 处理器处于非调试状态。

当处理器退出调试状态，且 "暂停调试步进" 处于活动状态时，处理器将执行如下 "暂停调试步进"：

1. 执行以下操作之一：
   • 执行下一条指令，不产生任何异常。
   • 采取任何优先级足够高的挂起异常条目。
   • 执行下一条指令，产生同步异常。

注意：只能捕获一个异常，即只能步进一个 PushStack()。

2. 将 DFSR.HALTED 置 1。
3. 返回调试状态。

注意：通过步进执行的指令读取 DFSR.HALTED 位时，会返回一个未知值。

调试器可选择将 DHCSR.C_MASKINTS 位设置为 1，以防止 PendSV、SysTick 和外部可配置中断被占用。当 DHCSR.C_MASKINTS 设置为 1 时，如果允许的异常处于活动状态，处理器将在执行相关异常处理程序的第一条指令之前单步进入并暂停。如表 C1-9 所示，DHCSR.{C_HALT、C_STEP、C_MASKINTS} 可以通过一次写入 DHCSR 来实现。

表 C1-9 使用 DHCSR 调试步进控制

a. 假定写入时 DHCSR.C_DEBUGEN 和 DHCSR.S_HALT 都设为 1，即系统已暂停。
b. 也就是说，根据异常优先级规则，异常会根据其配置变为活动状态。

写入 DHCSR 的效果在以下情况下无法预测：
• 写入更改了 DHCSR.C_MASKINTS，并且出现以下任一情况：
• 写入前，DHCSR.C_HALT 为 0。
• 写入后，DHCSR.C_HALT 从 1 变为 0。
除非两者都有：
• 在写入之前，DHCSR.C_DEBUGEN 为 0。
• 写操作将 DHCSR.C_MASKINTS 设置为 0。
• 写入操作将 DHCSR.C_DEBUGEN 从 0 更改为 1，并将 DHCSR.C_MASKINTS 设置为 1。

注意：要将 DHCSR.C_MASKINTS 置 1 并将 DHCSR.C_HALT 置 0，调试器必须首先写入 DHCSR，将 DHCSR.C_MASKINTS 设置为 1，然后再次写入 DHCSR，将 DHCSR.C_HALT 置 0。

当 DHCSR.C_DEBUGEN 为 1、DHCSR.S_HALT 为 0（即系统在启用了 "暂停调试" 支持的情况下运行）时，修改 DHCSR.C_STEP 或 DHCSR.C_MASKINTS 的效果无法预测。
当 DHCSR.C_DEBUGEN 为 0 时，处理器将忽略 DHCSR.C_HALT、DHCSR.C_STEP 和 DHCSR.C_MASKINTS 的值，这些值在 DHCSR 读取时是未知的。

Debug monitor stepping

标题：调试监视器步进

调试器可以使用 "调试监视器步进" 从 DebugMonitor 异常处理程序返回，执行单条指令，然后再次进入 DebugMonitor 异常处理程序。当以下情况全部适用时，"调试监视器步进" 处于激活状态：
• DHCSR.C_DEBUGEN 设置为 0，即禁用 "暂停调试"，请参阅 调试停机控制和状态寄存器，DHCSR 第 C1-696 页。
• DEMCR.MON_EN 设置为 1，表示启用 "监视器调试"，请参见第 C1-702 页上的 调试异常和监控控制寄存器，DEMCR。
• DEMCR.MON_STEP 设置为 1，启用 "监视器步进"。
• 执行优先级低于 DebugMonitor 异常的优先级。

当处理器从异常返回且 "调试监视器步进" 处于活跃状态时，处理器将执行如下 "调试监视器步进"：

1. 执行以下操作之一：
   • 执行下一条指令，不产生任何异常。
   • 采取任何优先级足够高的挂起异常条目。
   • 执行下一条指令，产生同步异常。

注意：只能捕获一个异常，即只能步进一个 PushStack()。

2. 如果执行优先级仍低于 DebugMonitor 异常的优先级，则设置 DEMCR.MON_PEND 位为 1。
3. 采取任何具有足够优先级的挂起异常。

如果在第 3 步，除 DebugMonitor 异常外，还有其他异常待处理，则适用正常的异常优先级规则。这意味着优先级高于 DebugMonitor 异常的其他异常可能会抢先执行。

否则，此过程的第 3 步将导致 DebugMonitor 异常抢先执行，并将控制权返回给 DebugMonitor 处理程序。除非该处理程序将 DEMCR.MON_STEP 清除为 0，否则从该处理程序返回将执行下一个调试监控步骤。

如果在步骤 1 或 3 之后，发生异常意味着执行优先级不再低于 DebugMonitor 异常的优先级，则 DEMCR.MON_STEP 和 DEMCR.MON_PEND 的值意味着当执行优先级回落到低于 DebugMonitor 异常的优先级时，"调试监视器步进" 过程将继续。

C1.5.2 Vector catch

标题：向量捕获
向量捕获是一种机制，用于生成调试事件，并在进入特定异常处理程序时进入调试状态。只有 "暂停调试" 才支持向量捕获。向量捕获的条件是：
• DHCSR.C_DEBUGEN 被置 1，请参阅第 C1-696 页上的 调试停止控制和状态寄存器 DHCSR。
• 相关故障状态寄存器状态位 被置 1。 请参阅第 B1-522 页上的 异常优先级和抢占。
• 相关向量捕获使能位（DEMCR[10:4,0]之一）被置 1。 请参见第 C1-702 页上的调试异常和监控控制寄存器 DEMCR。
• 异常会被送到相关的异常处理程序。
当满足这些条件时，处理器将暂停执行异常处理程序的第一条指令，并进入调试状态。

注意：
• 异常入口将故障状态位 置 1。调试器可以使用这些位来帮助确定错误源。更多信息，请参阅第 B3-605 页上的可配置优先级故障的状态寄存器、第 B3-608 页上的硬故障状态寄存器 HFSR 和第 C1-695 页上的调试故障状态寄存器 DFSR。
• 向量捕获机制保证处理器在进入调试状态时，不会在导致异常的指令之后执行任何指令。然而，保存的上下文可能包括锁定情况或优先级更高的待处理异常信息，例如复位时检测到的待处理 NMI 异常。

可能会出现晚到异常和派生异常，从而推迟处理器暂停的时间。更多信息，请参阅第 B1-542 页上的 晚到异常 和第 B1-543 页上的 异常输入时的派生异常。

异常进入时的异常

** 译者注： 本节对于 B1.5.11 章节*
在异常进入过程中，可能会出现其他异常，这可能是由于异常进入涉及的操作出现故障，也可能是由于异步异常（即中断）的出现，其优先级高于当前异常进入序列。
对于包含 FP 扩展的实现，另请参阅第 B1-562 页上的 "保存 FP 状态时的异常"。

晚到异常（延迟到达异常）

ARMv7-M 体系结构未指定异常进入期间处理器识别异步异常到达的时间点。但是，为了支持极低的中断延迟，该架构允许在异常进入期间到达的高优先级中断在该异常进入序列期间处于活跃状态，而不会导致进入序列重复。
当处理器在异常进入序列期间执行异步中断时，引起异常进入序列的异常称为原始异常。由中断引起的异常称为晚到异常。
在这种情况下，由原始异常启动的异常进入序列可被晚到异常使用。从晚到异常返回后，处理器会处理原异常。这被称为晚到抢占。
对于晚到的抢占，处理器会进入晚到异常的处理程序，并使其处于激活状态。原始异常仍处于待处理状态。
晚到异常可以是中断、故障或上级调用。
至于什么条件（如果有）会导致晚到抢占，则由实施情况决定。只有当迟到异常的优先级高于原始异常时，才会发生迟到抢占。如果实现支持晚到异常，LateArrival() 伪代码函数将显示其操作。该函数可更改 ExceptionTaken() 函数中使用的 ExceptionType 参数。

// LateArrival()
// =============
LateArrival()
	// xEpriority: the lower the value, the higher the priority 该值越小，优先级越高
	integer OEpriority; // original exception group priority 原始异常组优先级
	integer LAEpriority; // late-arriving exception group priority 晚到异常组优先级
	integer OEnumber; // ExceptionNumber for OE	原始异常号
	integer LAEnumber; // ExceptionNumber for LAE 晚到异常号
	if (LAEpriority < OEpriority) then
		ExceptionTaken(LAEnumber); // late-arriving exception taken
	else
		ExceptionTaken(OEnumber); // original exception taken

有关 ExceptionTaken() 的定义，请参阅第 B1-527 页上的 "异常输入行为"。

异常输入时的派生异常

当异常进入序列本身导致故障时，导致异常进入序列的异常称为原始异常。由异常进入序列引起的故障称为派生异常。原始异常发生时运行的代码流称为抢占代码，该代码的执行优先级为抢占优先级。
在异常进入过程中，可能会出现以下派生异常：
• 作为异常进入的一部分，向堆栈内存写入时出现 MemManage 故障。这被描述为 MSTKERR 类 MemManage 故障。
• 总线故障（BusFault）：作为异常进入的一部分对堆栈内存进行写入时发生的故障。这被描述为 STKERR 类总线故障。
• 未启用“暂停调试”时的观察点。这会在异常进入时导致 DebugMonitor 调试监视器异常。
• 读取原始异常向量时发生 BusFault 总线故障。这始终被视为硬故障。

如果抢占的优先级高于或等于派生异常的优先级，那么：
• 如果派生异常是 DebugMonitor 异常，处理器将忽略派生异常。
• 否则，处理器会将派生异常升级为 HardFault。

注意
当抢占的优先级高于或等于派生异常的优先级时，原始异常的优先级对处理器是否忽略 DebugMonitor 异常或升级派生异常没有影响。

派生异常的处理方式与晚到异常类似，执行程序可以使用晚到抢占来处理派生异常。只有当派生异常（在适当情况下升级后）的优先级高于原始异常时，才会发生晚到抢占，但究竟是什么条件（如果有的话）会导致晚到抢占，这是由实现定义的。
如果处理器不使用晚到抢占机制来处理派生异常，派生异常就会成为待处理异常，处理器会根据待处理异常的优先级规则来处理异常。
如果处理器使用晚到抢占机制处理派生异常，就会进入派生异常的处理程序，该处理程序就会处于激活状态。原始异常仍处于待处理状态。
DerivedLateArrival() 伪代码函数显示了这一操作。该函数更改了 ExceptionTaken() 函数中使用的 ExceptionType 参数。

// DerivedLateArrival()
// ====================
DerivedLateArrival()
	// xEpriority: the lower the value, the higher the priority 该值越小，优先级越高
	// PE: the pre-empted exception - before exception entry 抢占异常-异常进入之前
	// OE: the original exception - exception entry	原始异常-异常入口
	// DE: the derived exception - fault on exception entry 晚到异常-异常入口错误
	integer PEpriority; // pre-empted exception group priority
	integer OEpriority; // group priority of the original exception
	integer DEpriority; // derived exception group priority
	integer PEnumber; // ExceptionNumber for PE
	integer OEnumber; // ExceptionNumber for OE
	integer DEnumber; // ExceptionNumber for DE
	boolean DEisDbgMonFault; // DE is a DebugMonitor exception
	if DEpriority >= PEpriority && DEisDbgMonFault then
		ExceptionTaken(OEnumber); // ignore the DebugMonitor exception
	if DEpriority >= PEpriority && !DEisDbgMonFault then
		DEpriority = -1; // escalate DE to HardFault
						// (incl. BKPT with DebugMonitor disabled)
		SetPending(OEnumber); // OE to Pending state
		ExceptionTaken(HardFault);
	else
		if DEpriority < OEpriority then
			SetPending(OEnumber); // OE to Pending state
			ExceptionTaken(DEnumber); // start execution of the DE
									// tail-chaining IMPLEMENTATION DEFINED
		else
			SetPending(DEnumber); // DE to Pending state
			ExceptionTaken(OEnumber); // start execution of the OE

有关 ExceptionTaken() 和 PushStack() 的定义，请参阅第 B1-527 页的异常入口行为。
ICSR 和 SHCSR 维护待处理状态信息，请参阅第 B3-595 页的中断控制和状态寄存器 ICSR 和第 B3-603 页的系统处理程序控制和状态寄存器 SHCSR。

注意
是否支持晚到异常由实施确定，并可能影响派生异常。如果实现支持晚到异常，那么在第 B1-542 页的晚到异常中描述的晚到伪代码中，DE 与 OE 对应：
• DE 映射到 OE。
• 晚到异常映射到 SE。

C1.5.3 Debug event prioritization

标题：调试事件优先级
调试事件可以是同步的，也可以是异步的：
• 以下是同步调试事件：
• 断点调试事件，由执行 BKPT 指令或 FPB 中的匹配引起。
• 向量捕获调试事件。
• 步进调试事件，由 DHCSR.C_STEP 引起。
• 以下是异步调试事件：
• 观察点调试事件，包括 PC 匹配观察点。
• DHCSR.C_HALT 暂停请求调试事件。
• EDBGRQ 外部暂停请求调试事件。

一条指令可以产生多个同步调试事件。它还可以产生大量异步异常。以下原则适用于这些异常和调试事件的优先级排序：

• 产生 MPU 故障、默认内存映射导致的 XN 故障或总线错误的指令取指不能产生断点调试事件。

注意
如果取回单条指令会产生调试事件或在取回多条指令时中止，体系结构不会定义这些调试事件和中止之间的优先级。另请参阅第 A3-79 页上的单拷贝原子性。

• 单步、断点和向量捕获调试事件将代替执行指令。因此，当发生单步、断点和向量捕获调试事件时，处理器不会产生任何其他同步异常或调试事件，而这些异常或调试事件可能是执行该指令的结果。

注意
步进调试事件发生在指令被步进之后的指令上。这意味着该事件的优先级适用于后续指令的任何其他异常或调试事件，而不是被步进的指令。

• 如果一条指令有一个以上与之相关的调试事件，则无法预测是哪个调试事件：
• 步进。
• 断点。
• 向量捕获。
• 未定义的指令不会导致任何内存访问，因此不会导致 MPU 故障或外部中止异常或数据匹配观察点调试事件。
• 产生 MPU 故障的内存访问不能产生观察点调试事件。

除了单步所需外，ARM 体系结构并未定义何时发生异步调试事件。因此，异步调试事件的优先级由实施定义。
对于异步调试事件：
• 如果暂停，处理器必须在有限时间内进入调试状态。
• 如果作为 DebugMonitor 异常处理，且当前优先级低于 DebugMonitor 组优先级，则必须在有限时间内处理 DebugMonitor 异常。

C1.5.4 Exiting Debug state

处理器退出调试状态：
• 当调试器向 DHCSR.C_HALT 写 0 时，请参见第 C1-696 页的调试停止控制和状态寄存器 DHCSR。
• 收到外部重启请求时，请参见第 C1-688 页上的外部重启请求。
当处理器处于调试状态时，如果软件将 DHCSR.C_HALT 清零，随后读取 DHCSR 的 C_HALT 和 S_HALT 均返回 1，则表示处理器由于检测到新的调试事件而重新进入调试状态。

C1.6 Debug system registers

标题：调试系统寄存器
系统控制块 (SCB) 中的调试功能包括
• 两个与处理程序相关的标志位：ICSR.ISRPREEMPT 和 ICSR.ISRPENDING，请参见第 B3-595 页上的中断控制和状态寄存器 ICSR。
• DFSR 参见调试故障状态寄存器 DFSR。尽管 DFSR 是 SCB 寄存器，本节还是将其与其他调试寄存器一起介绍。

架构在调试控制块中定义了其他调试寄存器。表 C1-10 按地址顺序列出了这些寄存器。所有寄存器均为 32 位宽。有关 RW 寄存器复位值的详细信息，请参见寄存器说明。

C1.6.1 Debug Fault Status Register, DFSR

DFSR 的特征如下：
用途 显示发生了哪个调试事件。
使用限制 对寄存器位写 1 会将该位清零。通过步进执行的指令读取 HALTED 位会返回未知值。更多信息，请参阅第 C1-691 页上的调试步进。
配置 始终执行。
属性 参见第 B3-592 页的表 B3-4。上电复位会将已定义的寄存器位清除为 0。

DFSR 位分配如下

Bits[31:5] 保留，UNK/SBZP。
EXTERNAL, bit[4] 表示由于断言外部调试请求而产生的调试事件：
0 无外部调试请求调试事件。
1 外部调试请求调试事件。
VCATCH, bit[3] 表示触发了向量捕获：
0 未触发向量捕获。
1 触发向量捕获。
相应的 FSR 显示异常的主要原因。
DWTTRAP, bit[2] 表示 DWT 产生的调试事件：
0 DWT 未生成调试事件。
1 DWT 生成至少一个调试事件。
BKPT, bit[1] 表示 BKPT 指令执行或 FPB 中的断点匹配产生的调试事件：
0 无断点调试事件。
1 至少有一个断点调试事件。
HALTED, bit[0] 表示由以下任一情况产生的调试事件：
· 由写入 DHCSR 触发的 C_HALT 或 C_STEP 请求，参见 调试停止控制和状态寄存器 DHCSR。
· 通过将 DEMCR.MON_STEP 置 1 而触发的步进请求，请参阅第 C1-692 页上的 调试监控器步进。
0 无暂停请求调试事件。
1 暂停请求调试事件。

C1.6.2 Debug Halting Control and Status Register, DHCSR

DHCSR 的特性如下
用途 控制“暂停调试”。
使用限制
• 在启用了“暂停调试”的非调试状态下修改 C_STEP 或 C_MASKINTS 位的效果无法预测。
• 当 C_DEBUGEN 置 1 时，将启用“暂停调试”。 当 S_HALT 读数为 0 时，处理器处于非调试状态。
• 当 C_DEBUGEN 置 0 时，处理器将忽略寄存器中所有其他位的值。
• 调试器通常通过 DAP 访问 DHCSR。处理器上运行的软件可以更新寄存器中除 C_DEBUGEN 以外的所有字段。
• 处理器上运行的软件对 DHCSR 的访问由实施定义。
有关 DHCSR 使用的更多信息，请参阅第 C1-691 页上的调试步进。
配置 始终执行。
属性 参见第 C1-695 页的表 C1-10，以及寄存器字段说明。
DHCSR 位分配如下：

DBGKEY, bits[31:16]
调试密钥。调试器必须向该字段写入 0xA05F，才能启用对位[15:0]的写入访问，否则处理器将忽略写入访问。
这些位只允许写入。
Bits[31:26] 保留，UNK/SBZP。
S_RESET_ST, bit[25]
表示自上次读取 DHCSR 后处理器是否被重置：
0 上次读取 DHCSR 后没有复位。
1 上次读取 DHCSR 后至少复位过一次。
这是一个粘性位，在读取 DHCSR 时清零。
该位为只读。
S_RETIRE_ST，bit[24]
每次处理器退出一条或多条指令时设置为 1：
0 上次读取 DHCSR 后没有指令退出。
1 上次读取 DHCSR 后至少有一条指令退出。
这是一个粘性位，在读取 DHCSR 时清零。
架构并未精确定义何时将该位设置为 1，只要求在非调试状态下周期性地将该位设置为 1，以指示软件执行正在进行中。
上电或本地复位后，该位处于未知状态，但一旦处理器执行并退出指令，该位就会被置 1。
该位为只读。
Bits[23:20] 保留，UNK/SBZP。
S_LOCKUP，bit[19] 表示处理器是否因无法恢复的异常而被锁定：
0 未锁定。
1 锁定。
更多信息，请参见第 B1-551 页上的 无法恢复的异常情况（参见下文） 。
只有使用 DAP 的远程调试器才能将该位读取为 1。值为 1 表示处理器正在运行但被锁定。
当处理器进入调试状态时，该位清零。
该位为只读。
S_SLEEP，bit[18] 表示处理器是否处于休眠状态：
0 未休眠。
1 休眠。
调试器必须将 C_HALT 位设置为 1 才能获得控制权，或者等待中断或其他唤醒事件来唤醒系统。
该位为只读。
S_HALT，bit[17] 表示处理器是否处于调试状态：
0 处于非调试状态。
1 处于调试状态。
该位只读。
S_REGRDY，bit[16] 通过 DCRDR 传输的握手标志：
· 写入 DCRSR 会将该位清零。
· DCRDR 传输完成后，该位将置 1。
有关 DCRDR 传输的更多信息，请参阅第 C1-700 页上的 调试核心寄存器数据寄存器，DCRDR。
0 已向 DCRDR 写入，但传输未完成。
1 向 DCRDR 或从 DCRDR 的传输已完成。
该位仅在处理器处于调试状态时有效，否则为未知。
该位为只读。
Bits[15:6] 保留
C_SNAPSTALL，bit[5]
允许不精确地进入调试状态。写入该位的操作如下：
0 无操作。
1 允许不精确地进入调试状态，例如强制完成任何停滞的加载或存储指令。
将该位设置为 1 允许调试器请求不精确地进入调试状态。
除非 DHCSR 写入同时将 C_DEBUGEN 和 C_HALT 置 1，否则将该位设置为 1 的效果无法预测。 这意味着如果处理器尚未进入调试状态，则会在停滞指令完成后进入调试状态。
向该位写 1 会使内存系统的状态变得不可预测。因此，如果调试器向该位写 1，则必须在离开调试状态前复位处理器。

注意
调试器可以写入 DHCSR 将该位清除为 0，但这并不能消除将 C_SNAPSTALL 设置为 1 所导致的内存系统不可预测状态。
• 架构不保证将该位设置为 1 会强制进入调试状态。
• ARM 强烈建议，当处理器处于调试状态时，切勿将 1 的值写入 C_SNAPSTALL。

上电复位会将该位设置为 0。
Bit[4] 保留，UNK/SBZP。
C_MASKINTS，bit[3]
启用调试时，调试器可向该位写入信息，以屏蔽 PendSV、SysTick 和外部可配置中断：
0 不屏蔽。
1 屏蔽 PendSV、SysTick 和外部可配置中断。
任何试图更改该位值的尝试都将产生不可预知的影响，除非两者同时存在：
· 在写入 DHCSR 之前，C_HALT 位的值为 1。
· 写入 DHCSR 更改 C_MASKINTS 位的同时也将 C_HALT 位写入 1。
这意味着对 DHCSR 的单次写入无法将 C_HALT 设置为 0 并改变 C_MASKINTS 位的值。
该位不会影响 NMI。当 DHCSR.C_DEBUGEN 设置为 0 时，该位的值为未知。
有关使用该位的更多信息，请参阅第 C1-691 页上的 关闭调试步进。
上电复位后，该位为未知。
C_STEP，bit[2] 处理器步进位。写入该位的影响如下：
0 无影响。
1 启用单步。
有关使用该位的更多信息，请参阅第 C1-692 页上的表 C1-9。
当 DHCSR.C_DEBUGEN 设置为 0 时，该位的值为未知。上电复位后，该位为未知。
C_HALT，bit[1] 处理器暂停位。写入该位的影响如下：
如果处于调试状态，
0 使处理器离开调试状态。
1 暂停处理器。
第 C1-692 页上的表 C1-9 显示了处理器处于调试状态时写入该位的效果。
当 DHCSR.C_DEBUGEN 设置为 0 时，该位的值为未知。该位在上电复位后为未知，在本地复位后为 0。
C_DEBUGEN，bit[0] “暂停调试”启用位：
0 禁用。
1 启用。
如果调试器写入 DHCSR 将该位的值从 0 改为 1，则必须同时将 C_MASKINTS 位写入 0，否则其行为将无法预测。
该位只能由 DAP 写入，软件写入无效。
上电复位后，该位为 0。

有关该寄存器使用的更多信息，包括调试器如何在处理器复位后立即强制其进入调试状态的信息，请参见第 C1-691 页上的 调试步进。

B1.5.15 不可恢复的异常情况

ARMv7-M 体系结构通常假定，当处理器以优先级-1 或更高的级别运行时，发生的任何故障或监控程序调用都是完全意外和致命的。
标准异常进入机制不适用于优先级为-1 或更高的故障或监视器调用。ARMv7-M 要求处理器使用锁定机制处理大多数此类情况。其他情况则成为待处理或被忽略。锁定意味着处理器暂停正常指令执行并进入锁定状态。当处于锁定状态时
• 处理器从一个固定地址（即锁定地址）重复获取相同的指令，该地址由故障的性质决定，如第 B1-552 页所述，优先级小于 0 时执行可能出现的故障。
• 每次取回后，如果指令有效，处理器都会执行该指令。如果锁定是由具有基寄存器回写功能的加载或存储过程中的精确内存错误引起的，则故障会恢复基寄存器。
• 如果锁定发生时 IT 位非零，则 IT 位不会前进。
• 处理器将调试暂停控制和状态寄存器中的 S_LOCKUP 位设置为 1。
• 处理器将与导致锁定的故障一致的故障状态寄存器位设为 1。

ARM 强烈建议在实施过程中提供一个外部信号来指示处理器处于锁定状态，以便外部机制做出反应。

处理器可以通过以下方式退出锁定状态：
• 如果锁定处于 HardFault 处理器中，且发生 NMI 异常，则 NMI 将处于活动状态。NMI 返回链接是用于获取锁定状态指令的地址。
• 系统复位发生。这将导致退出锁定状态，并按正常方式重置系统。
• 处理器收到来自“暂停模式”调试代理的暂停命令。处理器进入调试状态 PC 设置为与返回上下文相同的值。小于 0 时可能出现的故障。
• 如果锁定是由内存错误引起的，并且该错误已通过系统的特定操作解决、 或随着时间的推移而解决。例如，内存错误可能是由需要时间配置的资源引起的、 因此当配置完成后，内存错误就会清除。
在大多数情况下，当处理器进入锁定状态时，它会一直处于该状态，直到复位（如看门狗复位）为止。
不过，可以使用以下机制来检查并纠正锁定状态的原因，从而有可能避免复位：
• 调试器通过发出 "暂停"（Halt）停止处理器，导致进入调试状态。然后修复一个或多个 xPSR、指令、FAULTMASK 和 PC，然后退出调试状态。
• 如果处理器因读取时出现总线故障而导致读取错误而锁死，外部主控程序可以纠正该问题，或者暂时性问题可以自我纠正。
• 如果处理器因指令未定义而锁死，外部主控程序可修改处理器获取指令的内存位置。
• 如果 NMI 在硬故障异常中抢先进入锁定状态，那么 NMI 处理程序可以在返回之前修复问题。返回。例如，它可能会更改返回 PC 值、更改 FAULTMASK 寄存器中的值，以及修复保存的 xPSR 中的状态位。
在这些情况下，处理器会退出锁定状态，并从锁定或修改后的 PC 地址继续执行、 如本节所述。

注意
尽管体系结构允许使用这些方法从锁定状态恢复，但 ARM 并不建议这些方法适合应用程序使用。方法适合应用程序使用。ARM 将锁定视为终止执行，需要复位。

以小于0的优先级执行时可能出现的错误

本节描述了当处理器以-1或更高的优先级执行时可能发生的所有错误或Supervisor调用的行为。这是指在执行HardFault、NMI或Reset处理程序期间或FAULTMASK设置为1时可能发生的故障。可能出现的故障如下:

• Vector read error at reset, when reading initial PC or SP value
• Vector read error on NMI entry, processor cannot read NMI vector
• Vector read error on HardFault entry, processor cannot read HardFault vector
• BusFault on instruction fetch
• BusFault on imprecise data access
• BusFault on precise data access
• BusFault on memory operation when stacking state on exception entry
• BusFault on memory operation when unstacking state on exception return
• MemManage fault on instruction fetch
• MemManage fault on data access
• MemManage fault on memory operation when stacking state on exception entry
• MemManage fault on memory operation when unstacking state on exception return
• Execution of SVC instruction
• INVPC UsageFault on exception return
• UsageFault other than INVPC
• Breakpoint triggered

C1.6.3 Debug Core Register Selector

Register, DCRSR

DCRSR 的特性如下：
目的 通过 DCRDR（请参阅第 C1-700 页上的调试核心寄存器数据寄存器 DCRDR），DCRSR 可提供对 ARM 核心寄存器、专用寄存器和浮点扩展寄存器的调试访问。写入 DCRSR 可指定要传输的寄存器、传输是读还是写，并开始传输。
使用限制 只能在调试状态下访问。
有关使用该寄存器的信息，请参阅第 C1-701 页上的DCRSR 和 DCRDR。
配置 始终执行。
属性 参见第 C1-695 页的表 C1-10。
DCRSR 位分配如下：

Bits[31:17] 保留
REGWnR，bit[16] 指定传输的访问类型：
0 读。
1 写。
Bits[15:7] 保留
REGSEL，bit[6:0] 指定要传输的 ARM 核心寄存器、专用寄存器或浮点扩展寄存器：
0b0000000-0b0001100 ARM 核心寄存器 R0-R12。例如，0b0000000 表示 R0，0b0000101 表示 R5。
0b0001101 当前 SP。另请参阅值 0b0010001 和 0b0010010。
0b0001110 LR。
0b0001111 DebugReturnAddress（调试返回地址），请参见第 C1-700 页上的 The DebugReturnAddress value（调试返回地址值）。
0b0010000 xPSR。
0b0010001 主堆栈指针，MSP。
0b0010010 进程堆栈指针，PSP。
0b0010100 :
• 位[31:24] CONTROL。
• 位[23:16] FAULTMASK。
• 位[15:8] BASEPRI。
• 位[7:0] PRIMASK。
在每个字段中，有效位都用前导零填充。例如，FAULTMASK 始终为单位 DCRDR[16]，而 DCRDR[23:17] 为 0b0000000。
0b0100001 浮点状态和控制寄存器，FPSCR。
0b1000000-0b1011111 FP 寄存器 S0-S31。例如，0b1000000 表示 S0，0b1000101 表示 S5。
所有其他值均为保留。

如果处理器没有实现 FP 扩展，则 REGSEL 字段为位[4:0]，位[6:5]为保留，SBZ。

注意 当处理器处于调试状态时，调试器必须保留 IPSR 中的异常编号位，否则其行为将无法判断。

有关 DCRSR 使用的更多信息，请参阅第 C1-701 页上的DCRSR 和 DCRDR。
有关调试器可通过 DCRSR 传输值的更多信息，请参阅：
• ARM 内核寄存器（第 B1-512 页），了解有关 R0-R12、SP 和 LR 的信息。
• 特殊用途程序状态寄存器 xPSR （第 B1-512 页）。
• 特殊用途掩码寄存器（第 B1-515 页），有关 FAULTMASK、BASEBRI 和 PRIMASK 的信息。
•· 特殊用途 CONTROL 寄存器（第 B1-515 页），了解有关 CONTROL 的信息。
• 浮点状态和控制寄存器 FPSCR（第 A2-37 页）。
• FP 扩展寄存器（有关 S0-S31 的信息，请参见第 A2-35 页）。

The DebugReturnAddress value

Debug Return Address 是退出调试模式时要执行的第一条指令的地址。该地址表示调试事件在执行流中的调用点。对于硬件或软件断点，这是断点指令的地址。对于所有其他调试事件（包括 PC 匹配监视点），DebugReturnAddress 是同时执行的第一条指令的地址：
· 在程序的简单顺序执行中，在引起调试事件的指令之后执行。
· 尚未执行。
在进入调试模式之前，处理器已经执行了程序简单顺序执行中比 DebugReturnAddress 所指示的指令更早的所有指令。
DebugReturnAddress 值的位[0]为 RAZ/SBZ。在写入 DebugReturnAddress 时，写入地址的位[0]不会影响 EPSR.T 位，请参阅第 B1-512 页上的专用程序状态寄存器 xPSR。

C1.6.4 Debug Core Register Data Register, DCRDR

DCRDR 的特点是
用途
• 通过 DCRSR（请参阅第 C1-699 页上的调试核心寄存器选择寄存器 DCRSR），DCRDR 可提供对 ARM 核心寄存器、专用寄存器和浮点扩展寄存器的调试访问。DCRDR 是这些访问的数据寄存器。
• DCRDR 单独使用时，可在外部调试器和处理器上运行的调试代理之间提供信息传递资源。

注意
架构没有为 DCRDR 的这种使用定义任何握手机制。

使用限制 有关适用于使用 DCRSR 和 DCRDR 的特定传输的限制，请参阅 Use of DCRSR and DCRDR。
配置 始终执行。
属性 参见第 C1-695 页上的表 C1-10。DCRDR 的复位值为未知。
DCRDR 位分配如下：

DBGTMP，位[31:0] 数据临时高速缓存，用于读写 ARM 内核寄存器、专用寄存器和浮点扩展寄存器。
该寄存器的值为未知：
• 复位时。
• 如果处理器处于调试状态，则调试器在进入调试状态后写入 DCRSR，DHCSR.S_REGRDY 设置为 0。

Use of DCRSR and DCRDR

在调试状态下，写入 DCRSR 会将 DHCSR.S_REGRDY 位清零，当 DCRDR 与 ARM 内核寄存器、专用寄存器或浮点扩展寄存器之间的传输完成后，处理器会将该位设置为 1。有关 DHCSR.S_REGRDY 位的更多信息，请参阅第 C1-696 页上的 调试停顿控制和状态寄存器，DHCSR。

这意味着
• 要将数据字传输到 ARM 内核寄存器、专用寄存器或浮点扩展寄存器，调试器需要：

1. 将所需字写入 DCRDR。
2. 写入 DCRSR，其中 REGSEL 值表示所需寄存器，REGWnR 位为 1 表示写入访问。
   该写操作将 DHCSR S_REGRDY 位清零。
3. 如果需要，轮询 DHCSR，直到 DHCSR.S_REGRDY 读为 1。这表明处理器已将 DCRDR 值传输到所选寄存器。

• 从 ARM 内核寄存器、专用寄存器或浮点扩展寄存器向调试器传输数据字：

1. 写入 DCRSR，REGSEL 值表示所需寄存器，REGWnR 位为 0 表示读取访问。
   该写操作会将 DHCSR.S_REGRDY 位清零。
2. 轮询 DHCSR，直到 DHCSR.S_REGRDY 读为 1。这表明处理器已将所选寄存器的值传输到 DCRDR。
3. 从 DCRDR 中读取所需的值。

使用该机制写入 ARM 内核寄存器、专用寄存器或浮点扩展寄存器时：
• xPSR 寄存器的所有位均可完全访问。写入非法值的影响无法预测。

注意
这与 MSR 和 MRS 指令访问 xPSR 的行为不同，在 MSR 和 MRS 指令中，写入时会忽略某些位 RAZ 和某些位。

• 调试器可以写入 EPSR.IT 位。如果这样做，必须写入与退出调试状态时要执行的指令一致的值，否则指令执行将无法预测。更多信息，请参阅第 A7-177 页上的 ITSTATE。如果 DebugReturnAddress 所指示的指令在 IT 块之外，则从调试状态退出时 IT 位必须为零。
• 调试器可以写入 EPSR.ICI 位，退出调试状态后，任何被中断的 LDM 或 STM 指令都将使用这些新值。将 ICI 位清零将导致被中断的 LDM 或 STM 指令重新启动，而不是继续执行。更多信息，请参阅第 B1-539 页上的 "加载多重操作和存储多重操作中的例外情况"。
• 调试器可以写入 DebugReturnAddress（调试返回地址），退出调试状态后，处理器将从该更新地址开始执行。调试器必须确保 EPSR.IT 位和 EPSR.ICI 位与新的 DebugReturnAddress 一致，如本列表所述。
• 调试器可以始终将 FAULTMASK 设为 1，但这样做可能会在退出调试状态时导致意想不到的行为。

注意
当执行优先级为 -1 或更高时，MSR 指令不能将 FAULTMASK 设置为 1，请参阅第 B5-673 页上的 MSR。

C1.6.5 Debug Exception and Monitor Control Register, DEMCR

DEMCR 的特征如下
目的 调试时管理向量捕获行为和调试监视器处理。
使用限制
• 位[23:16]提供调试监控器异常控制。
• 位[15:0]提供调试状态、暂停调试控制。
配置 始终执行。
属性 参见第 C1-695 页的表 C1-10，以及：
• 开机复位将所有寄存器位重置为零。
• 本地重置仅将与调试监控器相关的位重置为零。这些是位[19:16]。第 B1-526 页上的 "复位行为"定义了本地复位。

DEMCR 位分配如下

Bits[31:25] 保留
TRCENA，bit[24] 所有 DWT 和 ITM 功能的全局启用：
0 禁用 DWT 和 ITM 单元。
1 启用 DWT 和 ITM 单元。
如果未执行 DWT 和 ITM 单元，则该位为 UNK/SBZP。
当 TRCENA 设置为 0 时：
• DWT 寄存器在读取时返回 UNKNOWN 值。处理器是否忽略对 DWT 单元的写入取决于实施情况。
• ITM 寄存器在读取时返回未知值。处理器是否忽略对 ITM 单元的写入由实施情况决定。
将该位设置为 0 可能无法停止所有事件。为确保停止所有事件，软件必须将所有 DWT 和 ITM 功能使能位设置为 0，然后再将该位设置为 0。
该位对 TPIU、ETM 和其他系统跟踪组件的影响由实施定义。
Bits[23:20] 保留。
MON_REQ，bit[19] DebugMonitor 信号位。处理器不使用该位。监控软件定义了该位的含义和使用。
MON_STEP，bit[18] 当 MON_EN 设置为 0 时，禁用此功能，处理器忽略 MON_STEP。
当 MON_EN 设置为 1 时，MON_STEP 的含义为：
0 不步进处理器。
1 步进处理器。
将该位设置为 1 时，将等待步进请求。更多信息，请参阅第 C1-692 页上的调试监控步进。
在执行优先级低于 DebugMonitor 异常的优先级时更改该位的效果无法预测。
MON_PEND，bit[17] 设置或清除 DebugMonitor 异常的挂起状态：
0 清除 DebugMonitor 异常的状态为未挂起。
1 将 DebugMonitor 异常的状态设置为挂起。
当 DebugMonitor 异常处于挂起时，它会根据异常优先级规则处于活动状态。调试器可使用该位通过 DAP 唤醒监控器。
将该位设置为 1 的效果不受 MON_EN 位值的影响。调试器可以将 MON_PEND 设置为 1，即使在 MON_EN 设置为 0 的情况下，也可以强制处理器接受 DebugMonitor 异常。
MON_EN，bit[16] 启用 DebugMonitor 异常：
0 禁用“调试监控异常”。
1 启用“调试监控异常”。
如果 DHCSR.C_DEBUGEN 设置为 1，处理器将忽略该位的值。
有关 DebugMonitor 异常的更多信息，请参阅第 B1-519 页上的 ARMv7-M 异常模型。
Bit[15:11] 保留
VC_HARDERR，bit[10]
启用 HardFault 异常时的暂停调试陷阱。
0 禁用暂停调试陷阱。
1 启用暂停调试陷阱。
如果 DHCSR.C_DEBUGEN 设置为 0，处理器将忽略该位的值。
VC_INTERR，bit[9] 在异常进入或异常返回期间发生故障时启用暂停调试陷阱。
0 禁用暂停调试陷阱。
1 启用暂停调试陷阱。
如果 DHCSR.C_DEBUGEN 设置为 0，处理器将忽略该位的值。
VC_BUSERR，bit[8] 在总线故障异常时启用暂停调试陷阱。
0 禁用暂停调试陷阱。
1 启用暂停调试陷阱。
如果 DHCSR.C_DEBUGEN 设置为 0，处理器将忽略该位的值。
VC_STATERR，bit[7]
在由状态信息错误（例如未定义指令异常）引起的 UsageFault 异常时启用 "暂停调试陷阱"。
0 禁用暂停调试陷阱。
1 启用暂停调试陷阱。
如果 DHCSR.C_DEBUGEN 设置为 0，处理器将忽略该位的值。
VC_CHKERR，bit[6]
启用由检查错误（如对齐检查错误）引起的 UsageFault 异常时的暂停调试陷阱。
0 禁用暂停调试陷阱。
1 启用暂停调试陷阱。
如果 DHCSR.C_DEBUGEN 设置为 0，处理器将忽略该位的值。
VC_NOCPERR，bit[5]
在访问协处理器引起的使用故障（UsageFault）时启用 "暂停调试陷阱"。
0 禁用暂停调试陷阱。
1 启用暂停调试陷阱。
如果 DHCSR.C_DEBUGEN 设置为 0，处理器将忽略该位的值。
VC_MMERR，bit[4] 在 MemManage 异常时启用暂停调试陷阱。
0 禁用暂停调试陷阱。
1 启用暂停调试陷阱。
如果 DHCSR.C_DEBUGEN 设置为 0，处理器将忽略该位的值。
位[3:1] 保留
VC_CORERESET，bit[0]
启用复位向量捕获。这将导致本地复位，使运行中的系统暂停。
0 禁用复位向量捕获。
1 启用复位向量捕获。
如果 DHCSR.C_DEBUGEN 设置为 0，处理器将忽略该位的值。
第 B1-547 页上的 "故障行为"列出了所有故障及其对矢量捕捉启用位的分配。

本栏目推荐文章
• armv8虚拟化原理笔记
• IntelliJ IDEA Debug模式下结束后继续执行代码问题
• IDEA Debug 调试技巧(基础版)
• 解决mac arm 中 goland 无法 debug 问题
• 报错 To run and debug the Harmony device, configure the HarmonyOS runtime.
• Jax框架 —— 如何在没有GPU和TPU的设备上debug代码 —— 在CPU上使用GPU仿真设置 —— Jax框架在多卡设备上的自动并行特性的仿真体验
• 鸿蒙开发 ERROR: Failed to find the incremental input file: C:\Users\admin\.ohos\config\auto_debug_MyApplication2_com.example.myapplication2_2850086000448618441.cer.
• [Debug Series] Don't capture reference unless it's transient
• 将Debug目录下的所有文件打包成exe
• Debug正常编译运行但Release版报错分析

ARMv7 Debug ARMvarmv7 debug armv armv7 armv7-a 处理器armv7-a armv7 armv firmware-a firmware trusted armv7 armv armv8 armv8-a generic-armv armv8-m