STM32 上下文详解

STM32 基于 Cortex-M 内核（主流 M3/M4/M7/M0+），其上下文核心分为中断上下文 和RTOS 任务上下文两大类（裸机场景下主要涉及中断上下文，RTOS 场景下新增任务上下文），下面对每类上下文及组成部分做详细介绍。

一、中断上下文（裸机 / RTOS 场景均存在）

中断上下文是指当 STM32 触发中断（异常）时，为了保证中断服务程序执行完成后，主程序能从断点处无缝继续运行，需要保存的当前程序运行状态集合。中断上下文分为「硬件自动保存」和「软件手动保存」两部分，核心是寄存器状态。

1. 硬件自动保存的上下文（Cortex-M 内核硬件自动压栈）

当中断触发时，Cortex-M 内核会自动将 8 个核心寄存器压入当前栈（MSP 主栈 / PSP 进程栈，裸机默认 MSP，RTOS 任务默认 PSP），无需软件干预，这 8 个寄存器及详细说明如下：

寄存器	全称 / 别名	详细介绍（STM32 场景意义）
R0	通用寄存器 0	低组通用寄存器，是 ARM 架构中最常用的寄存器之一，用于临时数据存储、函数参数传递（ARM 函数调用规约中，第 1 个参数优先存在 R0）、算术 / 逻辑运算操作。中断发生时，R0 中存储着主程序当前正在处理的临时数据，若不保存，中断服务程序使用 R0 后会覆盖该数据，导致主程序运行异常。
R1	通用寄存器 1	低组通用寄存器，功能与 R0 类似，用于临时数据存储、函数第 2 个参数传递，是主程序运行的核心临时数据载体，必须由硬件自动保存。
R2	通用寄存器 2	低组通用寄存器，用于临时数据存储、函数第 3 个参数传递，承载主程序实时运算或数据搬运的中间值，硬件自动保存避免数据丢失。
R3	通用寄存器 3	低组通用寄存器，用于临时数据存储、函数第 4 个参数传递，同样是主程序运行的关键临时寄存器，硬件自动压栈保证断点状态完整性。
R12	通用寄存器 12（IP 寄存器）	通用寄存器，又称过程调用内部寄存器（Intra-Procedure Call），主要用于函数调用过程中的栈帧调整、临时数据中转（尤其是跨文件 / 跨函数调用时的中间数据缓存）。中断触发时，R12 的状态直接关联主程序的函数调用栈结构，需硬件自动保存。
LR	链接寄存器（R14）	有双重核心作用：① 主程序层面：存储主程序的「断点返回地址」（即中断触发时，主程序即将执行的下一条指令地址，保证中断返回后主程序能接续执行）；② 中断层面：Cortex-M 内核会自动给 LR 加载特殊返回值（如 0xFFFFFFF9/0xFFFFFFFD），用于指示中断返回后使用 MSP/PSP 栈，以及是否需要清理栈帧，是中断返回的核心标识寄存器。
PC	程序计数器（R15）	核心控制寄存器，存储当前即将执行的指令地址（STM32 的 Flash/ROM 中指令的地址）。中断触发时，硬件会自动保存主程序的下一条指令地址到 PC 并压栈，中断返回时，将该地址恢复到 PC 寄存器，主程序即可从断点处继续执行，不会出现指令执行错乱。
xPSR	程序状态寄存器（复合寄存器）	由 APSR（应用程序状态寄存器）、IPSR（中断程序状态寄存器）、EPSR（扩展程序状态寄存器）三部分组成，是程序运行状态的「总标识」：1. APSR：保存运算标志位（N：负数标志、Z：零标志、C：进位标志、V：溢出标志），主程序执行加减乘除、比较指令时会更新这些标志位，若不保存，中断服务程序的运算会覆盖标志位，导致主程序后续依赖标志位的逻辑（如条件判断）出错；2. IPSR：保存当前激活的中断异常号（如 STM32 的 EXTI0 中断对应异常号 6），用于内核识别当前中断源；3. EPSR：主要保存 Thumb 状态标志（T 位），因为 STM32 仅支持 Thumb/Thumb-2 指令集（不支持 ARM 指令集），该标志位确保中断返回后，CPU 仍能以正确的指令集执行主程序。

一、形参存储：R0-R3 优先承载前 4 个符合条件的形参

STM32 基于 Cortex-M 内核，遵循 ARM AAPCS（嵌入式架构应用程序调用规约，前身是 APCS），这是形参传递的核心规则：

基本规则 ：函数形参传递时，第 1 个形参存入 R0、第 2 个存入 R1、第 3 个存入 R2、第 4 个存入 R3。只有当形参数量超过 4 个，或形参不符合寄存器存储条件时，才会使用栈来传递剩余 / 不符合条件的形参。
条件限制 ：并非所有形参都能存入 R0-R3，只有满足「大小≤4 字节」且「类型适配」的形参（如 32 位整型int、字符型char、指针类型void*、短整型short等），才会按上述规则存入 R0-R3；若形参类型超过 4 字节（如 64 位long long、自定义大结构体、double浮点型等），则该形参不会存入 R0-R3，直接通过栈传递。
示例说明
- 对于函数 void func(int a, int b, int c, int d, int e)：a（R0）、b（R1）、c（R2）、d（R3），前 4 个形参存入寄存器，第 5 个形参 e 通过栈传递；
- 对于函数 void func(long long x, int y)：x 是 64 位类型（超过 4 字节），直接通过栈传递，y 作为第 2 个形参，仍存入 R1（此时 R0 未用于存储该函数形参）。

二、 R0-R3 的其他核心用途（并非仅用于形参传递）

除了函数形参传递，R0-R3 作为 Cortex-M 内核的低组通用寄存器，还有两个关键用途，这也是它们在 STM32 运行中的核心价值：

临时数据存储与运算载体 R0-R3 是 CPU 执行算术 / 逻辑运算、数据搬运时的「临时缓存」，用于存放运算的操作数和中间结果。例如执行 int sum = a + b; 时，编译器会先将 a 加载到 R0、b 加载到 R1，执行加法运算后，将结果暂存到 R0，再最终写入 sum 对应的内存地址（或其他寄存器）。这种用途不依赖函数调用，是 R0-R3 在程序运行中的基础用途。
函数返回值传递 对于 32 位以内的函数返回值（如int、char、指针等），函数执行完成后，会将返回值存入 R0 寄存器，主调函数通过读取 R0 的值来获取返回结果。这是 AAPCS 规约的明确要求，示例如下：

c

运行
复制代码
```
// 函数返回int类型（32位），返回值会存入R0
int add(int a, int b) {
    return a + b; // 运算结果先暂存，最终写入R0
}

void main() {
    int res = add(1,2); // 主调函数从R0中读取返回值，赋值给res
}
```

栈是怎么传递数据的

主调函数主导完成栈的准备、参数入栈，最终也由主调函数****完成栈清理，被调函数仅负责从栈中读取参数。下面结合具体流程和细节详细说明：

一、栈传递的核心前提

栈的生长方向 ：STM32 基于 Cortex-M 内核，使用满递减栈（FD 模式，Full Descending） ，即栈指针（SP，裸机用 MSP、RTOS 任务用 PSP）始终指向当前栈顶有效数据，参数入栈时 SP 向低地址方向 移动（栈占用空间扩大，栈可用剩余空间变小），栈清理时 SP 向高地址方向移动（释放栈空间）。
责任主体 ：栈传递的全流程（预留栈空间、参数入栈、栈空间释放）均由主调函数负责，被调函数无需关心栈的布局，仅需按规约从固定栈偏移位置读取参数即可，这是 ARM AAPCS 的明确要求。
参数筛选 ：只有两种情况会使用栈传递形参：① 形参数量超过 4 个，前 4 个符合条件的形参存入 R0-R3，剩余形参入栈；② 单个形参大小超过 4 字节（如 64 位long long、double，自定义大结构体等），该形参直接入栈（即使是第 1 个形参，也不占用 R0-R3）。

栈占用空间（已使用的栈空间）：指已经存放了有效数据（参数、寄存器值、局部变量等）的栈区域大小，一开始栈只指向栈顶，占用空间为0，数据入栈后，栈占用空间才变大。

栈可用剩余空间：指当前栈还能容纳新数据的空白区域大小，"往下放书后剩下的空间"，这个空间确实会变小。

书架场景	STM32 栈场景	固定 / 变化属性
书架整体高度	栈总容量（固定，如 1024 字节）	固定
书架顶部（最上方）	栈初始位置（高地址，如 0x20000400）	固定（初始）
书架底部（最下方）	栈底（低地址，如 0x20000000，不可跨越）	固定
已放的书（从顶部往下摆）	栈占用空间（已存放的有效数据）	变化（压栈增大，出栈减小）
最后一本放好的书	栈指针 SP（始终指向栈顶有效数据）	变化（压栈下移，出栈上移）
最后一本书到书架底部的空白区域	栈可用剩余空间（能放新书的空白区域）	变化（压栈减小，出栈增大）
放新书（往书架下方摆）	数据压栈 / 参数入栈	操作行为
拿旧书（往书架上方取）	数据出栈 / 栈清理	操作行为

二、栈传递的完整流程（分 4 步，附示例）

我们以一个具体函数调用为例，更易理解：

运行

复制代码

// 主调函数：调用func，形参数量5个（前4个存R0-R3，第5个e入栈），e是int类型（4字节）
void main(void) {
    int a=1, b=2, c=3, d=4, e=5;
    func(a, b, c, d, e); // 主调函数：负责栈传递e
    // 函数调用后，主调函数清理栈空间
}

// 被调函数：接收5个参数，前4个从R0-R3读取，第5个e从栈中读取
void func(int p1, int p2, int p3, int p4, int p5) {
    // 执行逻辑：p5（即e）从栈中读取
}

步骤 1：主调函数预留栈空间（调整 SP 指针）

主调函数在执行func(a,b,c,d,e)之前，会先计算需要入栈的参数总大小（本例中 e 是 4 字节，总大小 4 字节），然后通过减小栈指针 SP 的值，预留出对应的栈空间。

操作指令（汇编层面，编译器自动生成）：SUB SP, SP, #4（SP 减 4，预留 4 字节栈空间，对应 e 的大小）。
本质：栈是内存中的一块连续区域，减小 SP 相当于 "开辟" 出一块空白栈空间，用于存放待传递的参数。

步骤 2：主调函数按「从右往左」顺序将参数入栈

这是栈传递的关键规则：超出 / 大类型形参按「从右往左」的顺序依次压入栈中（即函数最右边的形参先入栈，最左边的超出形参最后入栈）。

本例解析：func 的形参顺序是 p1 (a)、p2 (b)、p3 (c)、p4 (d)、p5 (e)，其中 p5 (e) 是超出 4 个的形参，也是最右边的形参，因此先将 e 的值压入栈中。
操作指令（汇编层面）：STR R4, [SP]（假设 e 的值暂存在 R4 中，将其写入 SP 指向的栈顶地址，完成入栈；入栈后 SP 无需额外调整，因为步骤 1 已预留好空间）。
若有多个超出参数（如 func 有 6 个参数 f1-f6）：则先入栈 f6（最右），再入栈 f5，即入栈顺序为 f6 → f5（对应栈中地址：f5 在高地址，f6 在低地址，因为栈向下生长）。

步骤 3：被调函数通过「栈指针 + 偏移量」读取栈参数

被调函数执行时，已知前 4 个参数在 R0-R3 中，超出的参数在栈中，且栈布局遵循 AAPCS 规约，因此被调函数通过当前栈指针（SP）加上固定偏移量，即可精准读取栈中的参数。

本例解析：

被调函数进入后，会先执行函数序言（如压栈 LR、R4-R11 等，若有需要），此时 SP 会进一步减小，但编译器会记录基准偏移量；
对于参数 p5 (e)，被调函数通过 LDR R5, [SP, #偏移量]（偏移量由编译器计算，固定不变），从栈中读取 e 的值到 R5，供函数内部使用；
偏移量的计算：基于函数序言压栈的寄存器大小 + 预留栈空间的偏移，编译器自动完成，无需程序员手动干预。

大类型参数读取：若形参是 8 字节的long long类型，被调函数会通过两次栈读取（LDR R0, [SP, #offset]、LDR R1, [SP, #offset+4]），拼接得到完整的 64 位数据。

步骤 4：函数调用完成后，主调函数清理栈空间

当被调函数执行完毕返回主调函数后，主调函数会通过增加栈指针 SP 的值，释放之前为传递参数预留的栈空间，恢复栈到函数调用前的状态。

操作指令（汇编层面）：ADD SP, SP, #4（SP 加 4，释放步骤 1 预留的 4 字节空间，对应 e 的大小）；
若有多个超出参数（如 2 个 4 字节参数，总大小 8 字节），则执行ADD SP, SP, #8，一次性释放全部预留空间；
本质：栈清理仅调整 SP 指针，栈中的旧参数值不会被主动清除，但会被后续的栈操作覆盖，不影响程序运行。

三、大类型形参（＞4 字节）的栈传递补充说明

对于超过 4 字节的形参（如long long、double、自定义结构体），栈传递的核心逻辑与上述一致，仅需注意两点：

不占用 R0-R3 ：即使是第 1 个形参，只要大小＞4 字节，直接入栈传递（如void func(long long x, int y)，x 先入栈，y 存入 R0）；
按字节对齐入栈：ARM AAPCS 要求栈参数按 4 字节对齐（32 位内核），若形参大小不是 4 的整数倍（如 6 字节结构体），编译器会自动填充空白字节，确保对齐后再入栈，避免内存访问异常；
结构体传递优化：对于大结构体，编译器通常会先将结构体地址存入寄存器（R0），再将结构体数据拷贝到栈中，本质仍是栈传递，只是多了一层地址中转。

四、栈传递的直观示意图（基于上述示例）

假设函数调用前，SP 的初始值为0x20000400（STM32 的 SRAM 地址，高地址），栈传递过程的地址变化如下：

操作阶段	SP 值	栈地址	栈中数据	说明
函数调用前（初始状态）	0x20000400	-	-	SP 指向初始栈顶
步骤 1：预留栈空间	0x200003FC	-	-	SP 减 4，预留 4 字节空间
步骤 2：e 入栈（从右往左）	0x200003FC	0x200003FC	e=5	e 写入 SP 指向的栈顶地址
被调函数读取 p5 (e)	0x200003FC	0x200003FC	e=5	被调函数通过 SP + 偏移量读取
步骤 4：主调函数清理栈	0x20000400	0x200003FC	无效	SP 加 4，恢复初始栈状态

2. 软件手动保存的上下文（硬件未覆盖，需软件 / 编译器干预）

硬件仅自动保存上述 8 个寄存器，其余影响主程序运行的寄存器需手动保存，核心包括两类：

（1）通用寄存器 R4-R11

本质：高组通用寄存器，同样用于临时数据存储、函数局部变量缓存（ARM 函数调用规约中，R4-R11 属于「非易失性寄存器」，即函数调用 / 中断中若使用，必须保存原始值）。
保存原因：硬件未自动压栈，若中断服务程序中使用 R4-R11，会覆盖主程序中这些寄存器的原始值，导致主程序运行异常。
保存方式：① 若用 C 语言编写中断服务函数，STM32 编译器（如 Keil MDK、STM32CubeIDE）会自动在汇编层面插入PUSH {R4-R11}（压栈保存）和POP {R4-R11}（出栈恢复）指令；② 若用纯汇编编写中断服务程序，需程序员手动编写压栈 / 出栈指令。

（2）浮点寄存器（仅带 FPU 的 STM32 支持）

适用场景：仅 STM32F4/M4、STM32F7/M7、STM32H7 等带浮点运算单元（FPU）的芯片拥有。
组成：包括浮点数据寄存器 S0-S31、浮点状态控制寄存器 FPSCR 等。
保存原因：若中断服务程序中执行浮点运算（如 float/double 类型计算），会修改浮点寄存器的值，若不手动保存，会破坏主程序的浮点运算数据。
保存方式：需在中断服务程序开头手动压栈浮点寄存器，结尾手动出栈恢复；若启用 RTOS，部分 RTOS（如 FreeRTOS）会提供浮点上下文保存的封装接口。

二、 RTOS 任务上下文（仅 RTOS 场景存在，如 FreeRTOS/uC/OS）

当 STM32 运行 RTOS 时，任务上下文是指一个 RTOS 任务运行时的完整状态集合。当 RTOS 进行任务切换（如高优先级任务抢占低优先级任务、任务时间片耗尽）时，需将当前任务的上下文保存到该任务的独立任务栈中，再加载下一个就绪任务的上下文到 CPU 寄存器，保证任务切换后无缝接续运行。

RTOS 任务上下文是中断上下文的超集，核心组成及详细介绍如下：

1. 核心寄存器状态（完整通用寄存器 + 控制寄存器）

包含中断上下文中的所有寄存器（R0-R11、R12、LR、PC、xPSR），且是全集完整保存（无需区分硬件 / 软件保存，由 RTOS 统一处理），原因是任务切换是「主动暂停」，需要保存任务的全部运行状态，确保下次调度时能完全恢复。

2. 任务栈指针（PSP，进程栈指针）

Cortex-M 内核有两个栈指针：MSP（主栈指针，用于裸机主程序、中断服务程序、启动代码）、PSP（进程栈指针，专门用于 RTOS 任务）。
每个 RTOS 任务都有独立的任务栈，PSP 寄存器指向当前运行任务的栈顶。
任务切换时，RTOS 会将当前任务的 PSP 值保存到该任务的「任务控制块」（TCB，如 FreeRTOS 的TCB_t结构体）中，再从下一个任务的 TCB 中读取其 PSP 值并加载到 CPU 的 PSP 寄存器，实现任务栈的切换。

3. 浮点寄存器（若启用 FPU）

与中断上下文一致，带 FPU 的 STM32 中，若任务使用浮点运算，RTOS 会将 S0-S31、FPSCR 等浮点寄存器完整保存到任务栈中，避免任务切换后浮点运算状态丢失。

4. 任务状态附加信息

这是 RTOS 任务上下文的特有组成，不属于寄存器状态，但决定了任务的调度和恢复，核心包括：

任务优先级：任务的调度优先级（如 FreeRTOS 的 0-31 级），用于 RTOS 调度器判断任务的执行顺序。
任务状态：任务当前的运行状态（就绪 / 运行 / 阻塞 / 挂起），确保 RTOS 能正确识别任务是否可调度。
任务控制块（TCB）指针：指向当前任务的 TCB 结构体，TCB 中存储了任务栈地址、PSP 值、任务优先级、任务状态等核心信息，是 RTOS 管理任务的核心载体。
断点执行信息：除 PC 寄存器外，还包含任务的函数调用栈、局部变量等（存储在任务栈中），确保任务恢复后能从上次暂停的代码行继续执行。

裸机场景下 STM32 MSP（主栈指针）详细介绍

首先明确核心定位：MSP（Main Stack Pointer，主栈指针）是 Cortex-M 内核的核心栈指针之一，在裸机场景中，它是唯一被使用的栈指针，全程主导所有栈操作，承载着程序运行所需的各类栈存储需求。下面从定义、初始化、核心作用、关键特性等方面展开详细说明：

一、 MSP 的核心基础信息

全称与别名 ：Main Stack Pointer（主栈指针），别名SP_main，在 Cortex-M 内核中，它是一个 32 位专用寄存器（仅用于存储栈地址，不可作为通用数据寄存器使用）。
与 SP 的关系 ：Cortex-M 内核有两个栈指针（MSP 和 PSP），但裸机场景下不使用 PSP（进程栈指针，仅 RTOS 任务使用），此时MSP 就是默认的栈指针 SP，所有栈操作（压栈 / 出栈）均通过 MSP 完成，程序中提及的 SP（栈指针）本质就是 MSP。
栈模式适配 ：完全遵循 STM32 Cortex-M 内核的满递减栈（FD 模式） （这是你之前已了解的栈特性，MSP 作为栈指针严格遵守该模式）：
- 满：MSP 始终指向当前栈顶的有效数据（而非空白空闲区域）；
- 递减：压栈时 MSP 向低地址方向移动（地址数值减小），出栈时向高地址方向移动（地址数值增大）。

二、裸机场景下 MSP 的初始化流程（上电后自动完成，无需用户干预）

MSP 的初始化是 STM32 上电复位后最先执行的操作之一，全程由启动文件（汇编文件startup_stm32xxx.s）和链接脚本（xxx.ld）配合完成，分为两个关键步骤：

步骤 1：链接脚本配置 MSP 的初始栈顶与栈容量

链接脚本先定义栈的核心参数，为 MSP 初始化提供地址依据，典型配置代码如下（以 STM32CubeIDE 为例）：

复制代码

/* 1. 配置栈总容量（裸机场景固定，如0x400字节=1024字节） */
Stack_Size    = 0x400;

/* 2. 定义栈空间（从初始栈顶向下分配Stack_Size大小的连续内存） */
SECTIONS
{
  .stack :
  {
    . = ALIGN(4);          /* 栈地址4字节对齐，Cortex-M内核要求 */
    __StackLimit = .;      /* 栈底地址（低地址，不可跨越，固定不变） */
    . += Stack_Size;       /* 分配栈容量，向高地址延伸 */
    _estack = .;           /* 初始栈顶地址（高地址，MSP的初始值） */
  } >RAM                   /* 栈空间分配在SRAM中（STM32的RAM是可读写区域） */
}

关键参数：
_estack：初始栈顶地址（如0x20000400），是 MSP 上电后的初始值；
__StackLimit：栈底地址（如0x20000000），是栈的最低地址边界，MSP 不可低于该地址（否则触发栈溢出）；
Stack_Size：裸机栈总容量（固定值，由用户配置，通常根据程序需求设置为 0x400~0x1000 字节）。

步骤 2：启动文件初始化 MSP 寄存器（上电复位后立即执行）

STM32 上电复位后，不会直接进入main函数，而是先执行启动文件的汇编代码，第一步就是初始化 MSP，典型代码如下：

asm

复制代码

; 启动文件 startup_stm32f103.s
Reset_Handler:  /* 复位中断服务程序，上电后第一个执行的函数 */
  ; 1. 加载初始栈顶地址_estack到通用寄存器r0
  LDR     r0, =_estack
  ; 2. 将r0中的_estack值写入MSP寄存器，完成MSP初始化
  MOV     msp, r0
  ; 后续步骤：初始化堆、调用SystemInit()、进入main函数...
  BL      SystemInit
  BL      main
  ; main函数返回后，进入死循环
  B       .

初始化结果：MSP 寄存器被赋予_estack的地址值（如0x20000400），此时 MSP 指向初始栈顶，栈占用空间为 0（理论理想状态），随后随程序运行（函数调用、中断触发等）自动更新 MSP 的值。

三、裸机场景下 MSP 的核心作用（全程主导所有栈操作）

在裸机无 RTOS 的环境中，MSP 承担了所有栈相关的核心功能，是程序正常运行的基础保障，主要作用如下：

1. 承载函数调用的所有栈需求

裸机中函数调用的参数传递、返回地址、寄存器保护、局部变量存储，均通过 MSP 指向的栈完成：

超出 4 个的形参传递：前 4 个符合条件的形参存入 R0-R3，剩余参数由主调函数通过 MSP 压栈（从右往左入栈），被调函数通过 MSP + 偏移量读取；
函数返回地址存储：函数调用时，LR 寄存器（返回地址）自动压入 MSP 栈中，函数执行完成后，从 MSP 栈中弹出返回地址到 PC 寄存器，实现函数正常返回；
寄存器保护：函数序言（编译器自动生成）会将 R4-R11 寄存器压入 MSP 栈中（非易失性寄存器保护），函数尾声再从 MSP 栈中弹出恢复；
局部变量存储：函数内定义的局部变量（如int a = 1;），若未被编译器优化到寄存器中，会被分配到 MSP 指向的栈空间中，函数执行完毕后随栈出栈自动释放。

2. 存储中断上下文（裸机中断的唯一栈载体）

裸机场景下，中断触发后全程使用 MSP 存储中断上下文，无需切换 PSP：

硬件自动压栈：中断触发时，内核自动将 R0-R3、R12、LR、PC、xPSR 这 8 个寄存器压入 MSP 指向的栈中；
软件手动压栈：编译器自动将 R4-R11（及浮点寄存器，若有）压入 MSP 栈中；
上下文恢复：中断返回时，从 MSP 栈中依次弹出软件保存的寄存器和硬件保存的寄存器，同时 MSP 自动还原到中断触发前的状态。

3. 支撑异常处理（除中断外的其他内核异常）

STM32 Cortex-M 内核的非中断异常（如硬故障、总线故障等），在裸机场景下也会使用 MSP 存储异常上下文，确保异常处理完成后，程序能（或尝试）恢复正常运行，其栈操作逻辑与中断完全一致。

4. 作为程序运行状态的 "指示器"

MSP 的地址值变化可反映程序的运行状态，便于裸机程序调试：

MSP 向低地址移动（地址数值减小）：说明程序正在执行压栈操作（函数调用、中断触发、局部变量分配等）；
MSP 向高地址移动（地址数值增大）：说明程序正在执行出栈操作（函数返回、中断返回、栈清理等）；
MSP 接近__StackLimit（栈底）：说明栈占用空间即将耗尽，存在栈溢出风险（裸机程序需增大Stack_Size配置）。

四、裸机场景下 MSP 的关键特性

全程独占性：裸机无任务切换需求，无需使用 PSP，MSP 是唯一的栈指针，独占所有栈操作，不存在栈指针切换的情况（与 RTOS 场景本质区别）；
栈空间固定性 ：MSP 对应的栈空间由链接脚本Stack_Size固定，上电后栈底（__StackLimit）和初始栈顶（_estack）不再变化，仅 MSP 指针随栈操作移动；
自动更新性：MSP 的移动无需用户手动操作，由编译器（函数调用 / 局部变量）或内核硬件（中断 / 异常）自动完成，压栈时自动减 4（每 4 字节数据），出栈时自动加 4；
地址有效性 ：内核会隐性保护 MSP 不低于__StackLimit（栈底），若 MSP 低于该地址，会触发硬故障异常（栈溢出），导致程序死机（裸机场景下无自动恢复机制）；
指向有效性：始终遵循满递减栈特性，MSP 永远指向栈顶的最后一个有效数据，而非空白空闲区域，确保压栈 / 出栈操作的正确性。

五、直观示例：裸机 MSP 的地址变化过程

假设裸机栈配置：_estack=0x20000400（初始 MSP 值）、__StackLimit=0x20000000（栈底）、Stack_Size=0x400（1024 字节），程序运行过程中 MSP 变化如下：

上电初始化后：MSP=0x20000400（初始栈顶，栈占用空间 = 0）；
调用SystemInit()函数：函数序言压栈 R4-R11（32 字节），MSP=0x20000400-32=0x200003E0；
SystemInit()返回：函数尾声弹出 R4-R11，MSP 自动还原为 0x20000400；
进入main函数：函数序言压栈 LR、R4-R11（36 字节），MSP=0x20000400-36=0x200003DC；
main函数中调用func(a,b,c,d,e)（5 个 int 参数）：前 4 个参数存 R0-R3，第 5 个参数 e 压栈（4 字节），MSP=0x200003DC-4=0x200003D8；
触发外部中断：硬件自动压栈 8 个寄存器（32 字节），软件压栈 R4-R11（32 字节），MSP=0x200003D8-64=0x20000398；
中断返回：依次弹出软件保存寄存器和硬件保存寄存器，MSP 自动还原为 0x200003D8；
func函数返回：主调函数清理栈（释放 e 的 4 字节），MSP 还原为 0x200003DC。

补充：RTOS 任务上下文的切换载体

STM32+RTOS 的任务上下文切换，通常在PendSV 异常中完成（PendSV 是 Cortex-M 内核的可挂起异常，优先级可配置），原因是 PendSV 可延迟触发，不会打断紧急的中断服务程序，保证系统实时性。当需要任务切换时，RTOS 触发 PendSV 异常，在 PendSV 服务程序中完成当前任务上下文的保存和下一个任务上下文的加载。

总结

STM32 上下文核心分为「中断上下文」（裸机 / RTOS 通用）和「RTOS 任务上下文」（仅 RTOS 场景）；
中断上下文：硬件自动保存 R0-R3、R12、LR、PC、xPSR，软件手动保存 R4-R11 及浮点寄存器（若有），核心是保证主程序断点无缝恢复；
RTOS 任务上下文：是中断上下文的超集，完整保存通用寄存器、PSP 栈指针、浮点寄存器（若有）及任务状态信息，核心是保证任务切换后的无缝接续运行；
寄存器是上下文的核心载体，栈（MSP/PSP）是上下文的存储载体，中断 / PendSV 异常是上下文保存 / 恢复的触发场景。

STM32 上下文详解

一、 中断上下文（裸机 / RTOS 场景均存在）

1. 硬件自动保存的上下文（Cortex-M 内核硬件自动压栈）

一、 形参存储：R0-R3 优先承载前 4 个符合条件的形参

二、 R0-R3 的其他核心用途（并非仅用于形参传递）

栈是怎么传递数据的

一、 栈传递的核心前提

二、 栈传递的完整流程（分 4 步，附示例）

步骤 1：主调函数预留栈空间（调整 SP 指针）

步骤 2：主调函数按「从右往左」顺序将参数入栈

步骤 3：被调函数通过「栈指针 + 偏移量」读取栈参数

步骤 4：函数调用完成后，主调函数清理栈空间

三、 大类型形参（＞4 字节）的栈传递补充说明

四、 栈传递的直观示意图（基于上述示例）

2. 软件手动保存的上下文（硬件未覆盖，需软件 / 编译器干预）

（1） 通用寄存器 R4-R11

（2） 浮点寄存器（仅带 FPU 的 STM32 支持）

二、 RTOS 任务上下文（仅 RTOS 场景存在，如 FreeRTOS/uC/OS）

1. 核心寄存器状态（完整通用寄存器 + 控制寄存器）

2. 任务栈指针（PSP，进程栈指针）

3. 浮点寄存器（若启用 FPU）

4. 任务状态附加信息

裸机场景下 STM32 MSP（主栈指针）详细介绍

一、 MSP 的核心基础信息

二、 裸机场景下 MSP 的初始化流程（上电后自动完成，无需用户干预）

步骤 1：链接脚本配置 MSP 的初始栈顶与栈容量

步骤 2：启动文件初始化 MSP 寄存器（上电复位后立即执行）

三、 裸机场景下 MSP 的核心作用（全程主导所有栈操作）

1. 承载函数调用的所有栈需求

2. 存储中断上下文（裸机中断的唯一栈载体）

3. 支撑异常处理（除中断外的其他内核异常）

4. 作为程序运行状态的 "指示器"

四、 裸机场景下 MSP 的关键特性

五、 直观示例：裸机 MSP 的地址变化过程

补充：RTOS 任务上下文的切换载体

总结

一、中断上下文（裸机 / RTOS 场景均存在）

一、形参存储：R0-R3 优先承载前 4 个符合条件的形参

一、栈传递的核心前提

二、栈传递的完整流程（分 4 步，附示例）

三、大类型形参（＞4 字节）的栈传递补充说明

四、栈传递的直观示意图（基于上述示例）

（1）通用寄存器 R4-R11

（2）浮点寄存器（仅带 FPU 的 STM32 支持）

二、裸机场景下 MSP 的初始化流程（上电后自动完成，无需用户干预）

三、裸机场景下 MSP 的核心作用（全程主导所有栈操作）

四、裸机场景下 MSP 的关键特性

五、直观示例：裸机 MSP 的地址变化过程