做嵌入式这几年Cortex-M 和 Cortex-A 我两边都摸过。被问得最多的问题就是同样挂着 ARM 的招牌M 系列和 A 系列到底差在哪很多新手拿 M 核的经验去碰 A 核或者反过来一开始都容易懵。代码层面可能差异不大但真正一涉及中断嵌套、任务切换和异常现场恢复你就会发现两者的运行模式和寄存器组是完全不同的两套思路。今天就把这块掰开揉碎重点对比它们各自有哪些运行模式、寄存器是怎么组织的以及在开发中怎么利用这些差异。不管你是跑裸机、RTOS还是正在上手大型操作系统的移植搞清楚这些底层机制远比背几个主频和缓存参数更重要。1. 先看定位Cortex-M 和 Cortex-A 到底在争什么1.1 一个追求确定性一个追求吞吐量Cortex-M 系列主要面向微控制器领域强调“体积小、功耗低、中断延迟短”。它一般不带 MMU内存管理单元即使部分核配了 MPU内存保护单元也主要用来做访问权限限制而不是地址映射。常见场景是传感器节点、电机控制、物联网终端这类对实时性要求高、逻辑相对固定的设备。这类设备代码量不大跑裸机或者 FreeRTOS、RT-Thread 这类轻量级 RTOS 就够追求的是每次中断能在确定时间内完成响应。Cortex-A 系列则是应用处理器路线核心关键词是性能、多任务、虚拟内存。它标配 MMU可以跑大型操作系统多核调度、Cache 一致性、虚拟化扩展都属于它的基础能力。你可以把它理解成一台缩小的“电脑 CPU”处理复杂的计算任务时它更关注整体吞吐量和多任务公平性而不是某一个中断是否足够快。所以第一个要纠正的误区是不能说 A 系列一定比 M 系列“高级”。它们是在解决不同的问题。M 系列为了把中断响应做到足够快宁可放弃一些复杂特性A 系列为了承载操作系统和复杂计算愿意用更复杂的异常模型和更大的功耗换取整体性能。项目选型时如果只需要传感器采集和控制几个电机硬上一个 A 核高端芯片反而会带来电源、成本和启动时间的负担反过来如果想在上面跑神经网络推理和图形界面M 核的性能天花板又非常明显。1.2 运行模式和寄存器组才是差异的本质有些人喜欢用“能跑大型操作系统的是 A不能跑的是 M”来区分这只是一个表象。真正把这两个体系分开的是它们对异常和特权的组织方式。M 系列的异常模型很像“自动挡”中断来了硬件帮你把关键的寄存器压栈你只需要写一个短小的处理函数A 系列则像“手动挡”异常来了硬件只帮你切换到一个新模式的专属窗口剩下的现场保存要靠软件自己完成。这种差异最后都会落在两个具体问题上发生中断或异常后哪些寄存器由硬件保存哪些由软件保存不同优先级、不同模式之间切换是共用一套寄存器还是各自有独立副本这就是本文要对比的两条主线。把这两条线捋清楚你在写汇编启动代码、移植 RTOS 上下文切换、排查 HardFault 或段错误时会少走很多弯路。反过来说如果这两条线不清不楚你可能会花大量时间去调试一个其实已经被硬件处理得很明白的“灵异问题”。1.3 别急着套用M 的经验无法直接搬给 A我见过不少从 M 转到 A 的开发者第一反应是去找现成的启动文件然后把 M 的向量表和中断服务函数写法套上去结果很容易出问题。M 核的向量表在芯片内部每个中断一个入口用 C 语言写一个函数名就能注册A 核的异常向量表往往是跳板每个入口只有一条指令后面需要用户自己组装处理流程。更关键的是A 核有 CPSR 和 SPSR 的概念M 核只有 xPSRM 核一个 CONTROL 寄存器就能选堆栈A 核则是每个特权异常模式都有自己的 SP。这些不是语法差异是设计哲学差异。如果一开始不建立正确的模型后面每个异常处理都会踩坑。2. 运行模式对比从 M 的两种模式到 A 的七种模式2.1 Cortex-M线程模式与处理模式Cortex-M 内核运行模式只有两种线程模式Thread mode和处理模式Handler mode。线程模式是正常程序执行时的模式也就是 main 函数、任务函数、普通用户代码所在的地方处理模式是发生异常或中断时处理器自动进入的模式。这里要特别注意“特权级”和“运行模式”是两个维度。Cortex-M 还有两个特权等级特权级和用户级。线程模式既可以是特权级也可以是用户级而处理模式永远是特权级。这一点由 CONTROL 寄存器的 nPRIV 位控制nPRIV 为 0 时线程模式是特权级代码能直接操作绝大多数系统资源nPRIV 为 1 时线程模式变成用户级普通代码不能直接访问特殊寄存器、不能修改 MPU 配置也不能随意发起某些系统控制操作。如果用户代码想干这些事只能通过异常比如 SVC 指令进入处理模式由特权代码代为完成再返回。为什么要把模式和特权等级拆开因为这种设计能让“普通应用”和“内核/系统服务”在同一个 CPU 上实现轻量级分层但又不像 A 系列那么重。RTOS 里最常见的做法是任务跑在线程模式的用户级内核和中断跑在处理模式的特权级。任务栈用 PSP内核栈用 MSP互不污染。一个任务崩溃时至少还能靠 MPU 和特权等级保护核心系统状态这也是 M 核在工业控制里能站稳脚跟的重要原因。2.2 Cortex-A七种经典异常模式Cortex-A 在 AArch3232位状态下一般有七种运行模式User modeUSR普通用户程序模式特权最低不能直接修改 CPSR 的模式位和大部分系统配置。FIQ mode快速中断模式用于高优先级快中断。IRQ mode普通中断模式。Supervisor modeSVC管理模式通常由 SVC 指令触发系统内核大多跑在这里。Abort modeABT数据或指令中止模式内存访问异常时进入。Undefined modeUND未定义指令模式。System modeSYS与 User 模式共享寄存器但是拥有特权常见于内核中需要访问用户寄存器组的场景。Cortex-A 的每个异常模式都有自己的 SPSRSaved Program Status Register异常发生时会保存被中断模式的 CPSR同时异常模式也有自己独立的 SP 和 LR。比如 IRQ 中断来了硬件会把旧的 CPSR 存入 SPSR_irq把返回地址存入 LR_irq然后把 CPSR 的模式位切换成 IRQ 模式。这些动作在极短时间内由硬件完成但剩下的通用寄存器除了 FIQ 有自己的 R8-R12其他都要由软件入栈保存。所以 A 核的中断入口代码通常一开头就是一堆压栈指令退出时再恢复。如果考虑 ARMv7-A 的虚拟化扩展和 TrustZone 安全扩展还会看到 HYP mode 和 MON mode加上这两个功能模式数量会更多。而到 ARMv8-A 的 AArch64 状态开始改用 EL0、EL1、EL2、EL3 四级异常等级不再叫“模式”。这篇文章先以经典的七模式为主线后面会点一下 64 位下的对应关系。2.3 为什么 M 只需要两个模式A 却要这么多这个问题值得多问几遍。Cortex-M 的目标是低中断延迟和低功耗所以它把异常现场全部交给硬件压栈软件只管写中断函数。这就不需要在硬件里给每种异常准备一套“专属寄存器窗口”只要搞一个处理模式加两个堆栈指针就足够了。模式越少状态切换越简单硬件上要做的事情越少功耗和面积成本也越低。Cortex-A 则不同它要承载大型操作系统进程上下文、内核上下文、中断上下文必须严格分层。User mode 给普通进程SVC 给内核服务IRQ/FIQ 给中断Abort/Undef 给异常兜底。每种异常模式有自己的 SP、LR、SPSR意味着异常发生的那一瞬间处理器连“把现场存哪”都已经有固定答案了不需要再去共用栈上挤来挤去。用生活类比这就好比银行柜台每个窗口都有自己独立的抽屉多人同时办理业务互不干扰M 系列更像一个小便利店只有一个后台但靠硬件实现高效排队。对比维度Cortex-MCortex-AAArch32 为主运行模式线程/处理两种用户系统异常约7/9种特权设计特权/用户两级多种模式不同特权另扩展异常等级状态寄存器xPSRCPSR SPSR_堆栈指针MSP/PSP 两个由 CONTROL 切换每个特权异常模式各有独立 SP现场保存硬件自动压栈8个寄存器硬件只保存到SPSR/LR通用寄存器软件压栈快速中断优化自动压栈尾链FIQ独享R8-R123. 寄存器组结构对比处理器的“工位”长什么样3.1 Cortex-M 的寄存器格局Cortex-M 的寄存器组相对精简。R0-R12 是通用寄存器R13 是堆栈指针 SPR14 是链接寄存器 LRR15 是程序计数器 PC。它内部其实有物理独立的两套堆栈指针主堆栈指针 MSP 和处理堆栈指针 PSP。同一时刻到底用哪个由 CONTROL 寄存器的 SPSEL 位和异常返回序列共同决定。除了通用寄存器Cortex-M 还有几个特殊寄存器xPSR组合状态寄存器分成 APSR、IPSR、EPSR。通过读 IPSR 可以看到当前正在处理的中断号。PRIMASK屏蔽除 NMI 和 HardFault 以外的所有可配置优先级异常相当于一个总开关。FAULTMASK屏蔽除 NMI 以外的几乎所有异常作用比 PRIMASK 更强。BASEPRI按优先级阈值屏蔽中断比 PRIMASK 更精细适合需要保留部分高优先级中断的场景。CONTROL控制线程模式特权等级和堆栈指针选择。异常发生时Cortex-M 硬件会在自动压栈阶段把 xPSR、返回地址 PC、LR、R12、R3-R0 一共 8 个字按固定顺序压入当前栈。如果启用 FPU还会按情况压入浮点寄存器。这种硬件自动压栈的最大意义是“确定性”每次中断进入栈帧布局都是一样的RTOS 和调试器都能直接解析不需要软件在入口处写一堆保存代码。3.2 Cortex-A 的寄存器格局Cortex-A 在 AArch32 状态下也有 16 个基本通用寄存器R0-R15。其中R15 是 PCR14 是 LRR13 是 SP。但不同模式下的 R13、R14 并不共用物理寄存器而是各有副本FIQ 模式有 R13_fiq、R14_fiqIRQ 模式有 R13_irq、R14_irqSVC、ABT、UND 也各自拥有自己的 SP 和 LR。FIQ 模式还额外拥有 R8_fiq-R12_fiq这是普通模式下 R8-R12 的独立副本。这意味着FIQ 发生时会少压很多通用寄存器因此特别适合极低延迟的关键中断。CPSR 是 Cortex-A 的当前程序状态寄存器包含条件标志 N/Z/C/V、中断禁止位 I/F、Thumb 状态位 T、端序位 E以及最低 5 位的模式位 M[4:0]。异常发生时被中断的 CPSR 会自动保存到新模式的 SPSR 中而不是靠软件搬。返回时通过movs pc, lr或等价指令可以同时恢复 PC 和 CPSR。这里有个新手容易迷糊的点M 核是通过 xPSR 在栈帧里保存状态A 核则是通过 SPSR 保存状态M 核没有 SPSR 这样一个一个对应异常模式的影子状态寄存器。除了通用寄存器组A 核还有系统控制协处理器寄存器比如 CP15 相关寄存器用来配置 MMU、Cache、TLB以及异常向量表基址 VBAR。严格说它们不算内核通用寄存器组但在实操中经常要和模式切换一起使用。比如修改异常向量表基址就要先切到特权模式再操作 CP15 寄存器。3.3 几个容易忽略的寄存器细节第一Cortex-M 的 LR 在异常处理模式下会被硬件改写成一个 EXC_RETURN 特殊值。常见的值包括 0xFFFFFFF9、0xFFFFFFFD它们不是真实函数返回地址而是一串“异常返回指令代码”。通过 LR 最低几个 bit你可以判断返回后是进入线程模式还是继续处理模式以及返回时应使用 MSP 还是 PSP。所以如果在 ISR 里直接拿 LR 做函数调用或者把 LR 当成普通返回地址打印出来你会看到一堆 0xFFFFFF 开头的怪值。这不是芯片坏了是设计如此。第二Cortex-A 的 User mode 和 System mode 共享同一套寄存器但特权等级完全不同。User mode 不能直接修改 CPSR 模式位System mode 却可以。所以在 System 模式下访问 User 模式的寄存器视图时不需要切换模式就能拿到同样的 R0-R12、SP、LR这对内核调试和任务切换很有利。第三A 核的 SP 并不是全部都能随意改。不同异常模式有自己的 SP但某些模式下修改 SP 会直接影响当前栈位置一旦改错异常返回就会从一个非法地址取数据结果往往是死机。实操中启动代码里设置各模式 SP 的顺序很关键通常要先进入对应模式设好该模式的 SP再切到下一个模式。3.4 用一张表记住两种体系的关键差异维度Cortex-MCortex-AAArch32通用寄存器R0-R15R0-R15不同模式有banked副本状态寄存器xPSRCPSR另有各异常模式SPSR堆栈指针MSP/PSP 两个各特权模式独立SP自动压栈硬件压栈8个寄存器无通用寄存器自动压栈特权等级特权/用户两级多模式多等级外加EL典型代表裸机、RTOS大型操作系统、安全系统这张表的每一行都对应一套代码编写方式。比如在 M 核的 ISR 里你可以比较放心地让编译器使用 R0-R3、R12、LR因为异常进入时这些寄存器已经被硬件压栈函数返回后现场会自动恢复但在 A 核的 IRQ Handler 入口如果不先保存 R0-R12随便调用一个 C 函数就可能把现场打乱。这些差异实际操作中全是坑。4. 实战中的应用把模式与寄存器差距变成手里的工具4.1 Cortex-M 上用 PSP 跑任务用 MSP 跑中断RTOS 的上下文切换是 Cortex-M 运行模式最典型的应用场景。通常每个任务拥有自己的 PSP而中断和内核始终使用 MSP。任务的第一次启动需要先把任务初始化栈填好栈顶放好初始 xPSR、PC、LR 等再通过异常返回机制切到线程模式。以 PendSV 调度为例。PendSV 异常是专门用来做上下文切换的它本身是一个异常所以会进入 Handler mode并使用 MSP。在 PendSV Handler 中一般流程是; 进入 PendSV Handler 时硬件已自动压栈 xPSR, PC, LR, R12, R3-R0 ; 现在需要手动保存 R4-R11 到当前任务栈 MRS R0, PSP ; R0 当前任务栈指针 PSP STMFD R0!, {R4-R11} ; 手动保存 R4-R11 LDR R1, CurrentTCB STR R0, [R1] ; 保存任务栈指针到任务控制块 ; 选择下一个任务 LDR R1, NextTCB LDR R0, [R1] ; R0 新任务栈指针 LDMFD R0!, {R4-R11} ; 恢复 R4-R11 MSR PSP, R0 ; 更新 PSP BX LR ; 异常返回硬件自动从 PSP 弹出剩余现场这里的关键是为什么 R4-R11 要手动保存而 R0-R3、R12、LR、PC、xPSR 不用因为硬件自动压栈已经处理了后面那部分硬件不负责 R4-R11。所以调度器只需要关心编译器和调用规范里规定“必须跨函数调用保存”的寄存器即可。这也是 Cortex-M 上下文切换比很多老架构更简洁的原因。如果想限制任务特权你可以在任务初始化时把 CONTROL.nPRIV 设为 1任务运行在线程模式的用户级不能随便执行特权指令。一旦任务需要内核服务可以通过 SVC 指令主动触发异常切换到 Handler mode由特权代码处理后再返回。这种模式下任务与内核的边界非常清晰对产品安全性很有价值。4.2 Cortex-A 上通过 CPSR 判断和切换模式在 Cortex-A 裸机开发中启动代码里经常会做“切换模式”和“设置栈指针”的操作。写这些代码前最好先把当前模式读出来uint32_t cpsr; __asm volatile(mrs %0, cpsr : r(cpsr)); uint32_t mode cpsr 0x1F; switch (mode) { case 0x10: /* USR */ break; case 0x11: /* FIQ */ break; case 0x12: /* IRQ */ break; case 0x13: /* SVC */ break; case 0x17: /* ABT */ break; case 0x1B: /* UND */ break; case 0x1F: /* SYS */ break; default: /* unknown */ break; }Cortex-A 修改模式常用cps指令cps #0x13 ; 进入 SVC 模式 cps #0x12 ; 进入 IRQ 模式但注意User 模式下不能直接通过cps修改模式位也不能随便msr cpsr。普通应用想进内核必须执行 SVC 指令由 SVC 异常处理程序完成特权切换。这种由异常机制强制进入内核的方式是大型操作系统的系统调用基础。如果你在 User 模式里直接尝试修改受控的 CPSR 位处理器会进入未定义指令异常而不是“静默忽略”。一个经典的系统调用流程是应用代码执行SVC #0处理器切到 SVC 模式硬件把返回地址保存到 LR_svc把原 CPSR 保存到 SPSR_svc。然后 SVC Handler 从 LR_svc 附近取出 SVC 指令编码解析出系统调用号再根据 R0-R7 里的参数完成内核服务。返程时恢复现场回到用户模式继续跑。4.3 利用寄存器现场定位崩溃点调试 M 核时遇到 HardFault最直接的方法是把当前异常栈帧找出来。因为硬件压栈布局固定栈顶往上依次是 xPSR、PC、LR、R12、R3-R0所以只要找到 PC 位置基本就能定位到崩溃前行代码。配合调试器查看当前 LR 的 EXC_RETURN 值还能判断是在线程模式还是处理模式下崩的从而决定去检查哪个栈。调试 A 核时遇到 Abort 或 Undefined则要先看 SPSR_abort 或 SPSR_und再结合 LR 值计算异常发生地址。如果是 MMU 触发的 Abort还要去查 CP15 中的 Fault Address Register看看是哪个地址访问触发了异常。这个流程比 M 核多出好几步但只要记住“A 核的状态在 SPSRM 核的状态在栈帧”思路就不会乱。5. 常见问题与排查技巧实录5.1 任务栈总被莫名踩坏先查 MSP/PSP 是否选错症状任务运行一段时间后栈区数据被破坏或者出现 HardFault。可能的原因非常多但最典型的是 CONTROL.SPSEL 设置和当前使用的栈不匹配。比如某个任务明明应该在 PSP 上运行初始化时却把栈指针写错到 MSP一旦任务嵌套调用变深就会和内核共用栈互相踩踏。排查看两个关键点一是读 CONTROL 寄存器看当前线程模式到底选了哪个栈指针二是在异常返回时检查 LR 中的 EXC_RETURN 值。如果返回时应该使用 PSP但 CONTROL.SPSEL 还是 0CPU 就会从 MSP 里找一个并不存在的任务栈帧结果轻则返回地址错乱重则直接 HardFault。解决办法是规范化任务创建流程每个任务创建时在初始化栈中提前安排好 PSP并通过 RTOS 的上下文切换入口统一设置 CONTROL 和 PSP。5.2 在 A 核用户模式下写 CPSR直接进 UND症状程序执行到某条msr cpsr或cps指令后没按预期进入目标模式反而跳进了 Undefined 异常。原因User 模式是受限模式不能修改 CPSR 中的模式位、中断禁止位等特权信息。处理器不允许你直接提升自己的特权等级这是一种安全机制。如果你在无特权的 User 态尝试这些操作硬件就会认为当前指令未定义触发 Undefined 异常。正确做法是用 SVC 指令主动陷入内核在内核态完成特权操作再返回用户态。很多从 M 核转过来的开发者习惯在 main 函数里直接切换模式这在 M 核没毛病在 A 核就是大坑。记住A 核的 User 模式像一扇上锁的门开锁的钥匙是异常机制不是直接写 CPSR。5.3 中断里调用函数后现场一片混乱这个坑在两种核上表现不同。M 核因为在异常入口会自动压栈只要不是手写汇编C 编译器通常会正确处理 LR一般不会出大问题。但如果你在 ISR 里手写汇编并且没保存 LR 就调用子函数那么 LR 原本保存的 EXC_RETURN 会被函数调用覆盖。返回时试图用BX LR完成异常返回就会跳到一个被改过的“假地址”现场当然全乱。A 核则更隐蔽。进入异常模式后LR 里保存的是被中断模式的下一条指令地址还没保存到栈上。如果 Handler 里直接调用别的函数返回地址就会被覆盖。所以 A 核的异常入口必须先把 LR 和需要保护的通用寄存器压栈最后通过ldmfd sp!, {.., pc}^或movs pc, lr一类指令返回。这个“先压栈、后干活”的习惯在 A 核开发里是铁律。5.4 FIQ 不是“万能快中断”用之前先算清楚代价很多人以为 FIQ 全是优点有自己的 R8-R12不用压栈这些寄存器中断响应很快。但代价是FIQ 模式下R0-R7 仍然和普通模式共用如果中断处理程序里要修改 R0-R7照样需要保存。而且 FIQ 拥有独立的 SP、LR、SPSR会让启动代码和调试器需要额外处理一套寄存器视图。更关键的是系统里所有外设中断通常都走 GIC优先把某个外设配成 FIQ 后它的中断上下文和普通中断隔离如果你在 FIQ 里又调用一些依赖普通中断嵌套的代码容易出问题。我的建议是默认情况用 IRQ 就够了除非有特别明确、必须保证极低延迟的中断源才考虑 FIQ。不要为了“看起来更快”去引入一整套新的现场维护逻辑。这个判断和你是不是高手没关系而是和你对系统确定性要求的理解有关。5.5 查异常时先摆出“模式寄存器”再动手最后再说一个我带人做项目时最常强调的排查习惯遇到异常先别急着翻代码或者猜原因先把当前模式和寄存器现场摆出来。M 核看 CONTROL、EXC_RETURN、栈帧最上方的 xPSRA 核看 CPSR、SPSR、LR 和异常的 Fault Address 寄存器。很多时候问题的答案已经写在现场里了。比如 M 核 HardFault 的栈帧 PC 指向一个空指针跳转A 核 Abort 的 Fault Address 指向一个非法地址一眼就能看出问题根本不用反复试跑。这比盲猜快十倍前提是你真正理解了两套体系里寄存器和模式是怎么协作的。