是，但仅当ISR使用FPU时才惰性保存；默认不自动保存全部FPU寄存器，仅短栈帧（8个通用寄存器）被压栈，浮点寄存器S0–S31等仅在ISR实际执行FPU指令后由硬件延迟保存。
中断触发时FPU寄存器是否自动保存？
不自动。Cortex-M系列（如M4/M7）默认采用惰性压栈（Lazy Stacking）机制：只有当中断服务程序（ISR）真正使用了FPU寄存器，硬件才在进入ISR后*延迟*保存浮点上下文；若ISR全程未碰FPU指令，就只压入8个通用寄存器（短栈帧），不保存S0–S31等浮点寄存器。
这意味着：如果你的主任务用了sqrtf()、arm_mat_mult_f32()等函数，而ISR里调用了一个看似无关的printf()（内部可能隐式启用FPU），就会触发长栈帧——但此时主任务的FPU状态已被覆盖，返回后浮点计算结果错乱。
- 查证方法：在Keil或STM32CubeIDE中打开寄存器视图，观察进入ISR前后
CONTROL.FPCA和FPCCR.LSPACT位的变化 - 风险场景：主循环做PID浮点运算，ISR里调用带
float参数的log_printf()宏 → 惯性导致FPU上下文被破坏 - 编译器不会帮你检测这种隐式FPU使用，尤其在启用
-ffast-math或链接CMSIS-DSP库时
如何强制让所有中断都保存FPU上下文？
在启动代码（startup_*.s）或SystemInit()中设置CPACR并启用CONTROL.FPCA，再通过汇编指令显式开启“非惰性压栈”：
/* 启用FPU访问权限 */
ldr r0, =0xE000ED88 /* CPACR地址 */
ldr r1, [r0]
orr r1, r1, #(0xF << 20) /* 设置CP10/CP11为full access */
str r1, [r0]
<pre class="brush:php;toolbar:false;">/* 切换到特权线程模式 + 启用FPU上下文自动保存 */
mov r0, #0x04
msr control, r0 /* CONTROL.FPCA = 1 */
立即学习“C++免费学习笔记（深入）”；
这样所有中断都会无条件执行长栈帧（32字+浮点寄存器），避免上下文丢失，代价是每次中断多压约64字节、延迟增加约20–30个时钟周期。
- 仅对确实需要FPU的系统启用，纯整数任务开启反而浪费RAM和时间
- GCC下需额外加
-mfloat-abi=hard -mfpu=fpv4-d16，否则CONTROL.FPCA=1无效 - Keil中对应配置项是“Use FPU” + “Floating Point Hardware”设为“FPv4”
在ISR里安全使用FPU的最小实践
即使启用了FPU，也不该在中断上下文中直接跑复杂浮点运算——实时性、堆栈溢出、重入问题会立刻浮现。正确做法是把FPU操作推迟到主循环或RTOS任务中。
- ISR只做三件事：读取ADC值、写入环形缓冲区、置位
std::atomic<bool></bool>标志 - 主循环检测到标志后，禁用中断（
__disable_irq()）、拷贝缓冲区数据、在临界区外调用arm_filter_f32()等函数 - 若必须在ISR里算一次
sin()，确保该ISR永不嵌套，且栈空间预留≥512字节（含浮点寄存器+调用栈） - 绝对不要在ISR里调用
malloc()、printf()、new，这些函数内部可能触发FPU指令或动态分配
为什么CMSIS-DSP库函数容易引发FPU上下文混乱？
像arm_mat_mult_f32()、arm_pid_f32()这类函数，在GCC或ARMCC编译下会内联FPU指令（如vmla.f32），但它们不感知当前是否处于中断上下文。一旦被ISR调用，就会触发惰性压栈逻辑，而主任务的FPU状态已在压栈前被破坏。
典型现象：电机控制环路偶尔抖动，示波器看到PWM占空比跳变，debug发现S15寄存器值异常 —— 很可能就是某个低优先级中断偷偷执行了DSP函数，污染了高优先级控制任务的浮点寄存器。
- 解决方案一：所有DSP调用统一放在一个专用任务中，用RTOS信号量同步
- 解决方案二：对关键ISR使用
__attribute__((naked))+ 手写汇编，开头强制vmrs APSR_nzcv, fpscr再vpush {s0-s15}，结尾vpop恢复 - 更稳妥的做法：用定点数重写核心控制算法，彻底规避FPU上下文管理
FPU上下文保护不是“开个开关就完事”的配置问题，它横跨硬件行为、编译器生成代码、中断嵌套深度、栈空间规划四个层面。最容易被忽略的是：你没写的代码，可能比你写的代码更危险——比如标准库函数、DSP库、甚至编译器内建函数（__gnu_h2f_ieee）悄悄触发了FPU。
