简介：本资源是一份面向嵌入式开发工程师与ARM架构技术爱好者的STM32N6芯片启动机制深度解析文档，聚焦FSBL（第一阶段引导加载程序）的原理、流程与工程实践，解决开发者在新平台启动适配、安全签名及XIP/Load&Run模式选型中的核心困惑。文档系统梳理了Dev boot与Flash/Serial boot两种启动模式，详解FSBL校验搬运、APP加载执行、外部Flash原位执行（XiP）三大典型流程，并配套ST官方Signing Tool的CLI签名命令、Header版本差异（hv 2.1/hv 2.3）及环境配置要点，辅以IAR+STM32N6 DK板的完整示例项目开发路径。资源为单文件PDF，共1个文件，大小2.07MB，内容结构清晰、图示丰富（含6幅关键流程图），覆盖从BootROM验证机制到实际部署的全链路。目前已有160人学习下载，适合具备Cortex-M基础、正迁移至STM32N6平台并需掌握NPU MCU安全启动体系的中高级开发者。

1. FSBL 不是“启动代码”，而是 BootROM 的「信任代理」：为什么 STM32N6 上电后连 main() 都没见着，就先崩在 0x34180000？

你写完一个 UART 打印 demo，IAR 编译通过、调试器 attach 成功、串口稳稳吐出 “Hello from STM32N6”，一切丝滑——直到你把 bin 文件烧进外部 Flash，拨好 BOOT1=0，按下复位键：板子沉默，ST-Link 连不上，CubeProgrammer 报错 “No device found” 或 “Failed to read ROM Table”。你翻遍工程配置、检查 Flash 地址、重刷 bootloader……最后发现，问题既不在链接脚本，也不在时钟初始化，而是在上电那一瞬间——BootROM 根本没让 FSBL 跑起来。它在 0x70000000 处读到的不是合法签名头，而是你裸编译出来的原始二进制。这不是“程序没烧对”，这是硬件级信任链的第一道门禁直接把你拒之门外。

STM32N6 的启动机制，本质是一场由片内 ROM 主导的「可信执行环境准入审查」。它不关心你代码逻辑多优雅、算法多高效，只认一个东西：FSBL 二进制头部是否通过 ST 签名工具生成的、带特定 magic、version、hash 和校验字段的 1024 字节结构体。这个结构体不是软件约定，是 BootROM 固件硬编码解析的协议；这个地址 0x70000000 不是随便选的，是 Flash 映射空间中 BootROM 唯一信任的加载起点；而那个跳转目标 0x34180000，也不是 SRAM 的任意位置，是 BootROM 内部搬运逻辑预设的、带 MPU 保护的执行区。换句话说，FSBL 在 STM32N6 上根本不是传统意义的“引导程序”，它是 BootROM 为自身能力做的一次可信延伸——BootROM 只负责验证和搬运，FSBL 才真正接管后续所有控制权。搞不清这个前提，所有“为什么烧不进去”“为什么跑飞了”“为什么 attach 失败”的问题，都会变成玄学排查。本文就带你一层层撕开这个黑匣子：从 BootROM 如何用 1024 字节 header 做准入审计，到 FSBL 如何在 SRAM 中完成身份切换；从签名工具里 -hv 2.1 和 -hv 2.3 的微小差异如何对应芯片 Cut 版本的 ROM 行为变更，到 Load&Run 与 XiP 两种模式下内存视图的根本性分裂。这不是一份操作手册，而是一份 BootROM 与 FSBL 之间信任交接的源码级契约解读。

2. BootROM：固化在硅中的「启动宪法」，它的每条指令都在执行一次不可绕过的信任仲裁

BootROM 是 STM32N6 启动流程中唯一不可修改、不可 bypass、不可 debug 的绝对权威。它不是一段可配置的固件，而是掩膜 ROM（Mask ROM）中物理刻写的微码序列，出厂即固化，生命周期内永不变更。它的存在目的极其单一：在任何用户代码执行前，完成三件事——确认启动源合法性、验证下一阶段代码完整性、将可信代码载入受控内存并跳转。这三步构成了一条硬件强制的启动信任链（Chain of Trust），而 FSBL 就是这条链上第一个、也是唯一被 BootROM 直接认证的环节。

2.1 BootROM 的启动决策树：BOOT1 引脚不是“选择开关”，而是「信任域入口凭证」

文档中提到 BOOT1 引脚决定 dev boot 或 flash boot 模式，但这个描述容易误导。实际上，BOOT1 并不直接控制“从哪启动”，而是向 BootROM 提交一个启动策略声明（Boot Policy Declaration）。BootROM 在复位退出后，首先读取 BOOT1 和 BOOT0 的电平组合，据此确定本次上电应启用哪套信任仲裁规则：

• Dev boot 模式（BOOT1=1, BOOT0=x）：BootROM 跳过所有签名验证，直接尝试从内部 SRAM（起始地址 0x30000000）读取并执行代码。此时它不检查 header，不搬运，不校验 hash，纯粹是“开发者特权通道”。但注意：该模式下 BootROM 仍会执行基本的 SRAM 初始化（如清除未初始化段）、MPU 配置（若使能），且仅限调试使用——一旦芯片进入量产状态，该路径通常被熔丝锁死或功能降级。

• Flash boot / Serial boot 模式（BOOT1=0, BOOT0=0）：BootROM 进入严格仲裁模式。它会：

  1. 检查外部 Flash（默认映射在 0x70000000）起始位置是否存在有效 header；
  2. 若存在，解析 header 中的magic（固定为0x53544D32，即 ASCII "STM2"）、header_version（如 2.1/2.3）、image_size、hash_algo（SHA-256）、signature_offset等字段；
  3. 使用内置的公钥（硬编码于 ROM 中，对应 ST 私钥签发）验证 header 后紧随的 signature 区域；
  4. 若验证失败，BootROM 立即 halt，不报错、不输出、不响应 SWD，表现为“板子变砖”；
  5. 若验证成功，则按 header 中load_address（固定为 0x34180000）将整个 image（含 header + code + data）搬运至 SRAM2，并跳转执行。

提示：BootROM 不解析.bin文件格式，它只读取 raw memory。因此烧录时必须确保FSBL-trusted.bin的首字节严格对齐到 Flash 的 0x70000000 地址。若用 hex 文件烧录却未指定-addr参数，IAR/Keil 默认将代码链接到 RAM 地址（如 0x30000000），导致 Flash 0x70000000 处为全 0xFF，BootROM 读到无效 magic 直接 abort。

2.2 Header 结构：1024 字节里的「宪法条款」，每个字段都是 BootROM 解析器的硬性语法

FSBL 的 header 不是可选元数据，而是 BootROM 解析器的输入语法。其结构由 ST 签名工具严格生成，无法手写。我们以 Cut1.1 版本（-hv 2.1）为例，反推其典型布局（基于 ST 官方 SigningTool CLI 输出及 ROM 行为逆向）：

// FSBL header layout (v2.1, 1024 bytes total) typedef struct { uint32_t magic; // 0x53544D32 ("STM2") uint32_t header_version; // 0x00020001 (2.1) uint32_t image_size; // Total size of FSBL image (code+data), excluding header uint32_t load_address; // 0x34180000 (SRAM2 base) uint32_t entry_point; // Offset from load_address where execution starts (e.g., 0x00000100) uint32_t hash_algo; // 0x00000001 (SHA-256) uint32_t signature_offset; // Offset from header start to signature block (e.g., 0x00000400) uint32_t reserved[246]; // Padding to 1024 bytes uint8_t hash[32]; // SHA-256 of (header without hash/signature + image body) uint8_t signature[256]; // ECDSA P-256 signature over hash } fsbl_header_t;

关键点在于：

• magic和header_version是 BootROM 解析器的“协议握手信号”。若版本不匹配（如 Cut2.0 芯片用 hv2.1 签名），BootROM 会拒绝解析，即使其他字段全对；
• image_size决定了 BootROM 搬运多少字节。若实际 bin 文件长度与此不符，搬运会越界或截断，导致 SRAM 中代码损坏；
• load_address和entry_point共同决定了 PC 跳转目标。BootROM 不解析 ELF 符号，它只做 raw copy + absolute jump；
• hash和signature构成密码学绑定。BootROM 内置 ECDSA 验证引擎，用 ROM 中硬编码的 ST 公钥解密 signature，比对计算出的 hash。任何字节篡改都会导致 hash mismatch。

2.3 BootROM 的搬运与跳转：为什么是 0x34180000？SRAM2 的 MPU 保护才是关键

BootROM 将 FSBL 搬运至0x34180000，这个地址绝非随意指定。STM32N6 的 SRAM2（192KB）被划分为多个 MPU region，其中0x34180000–0x341BFFFF（256KB）被 BootROM 预配置为：

• 可执行（XN = 0）
• 可读写（R/W）
• 特权级访问（PRIV = 1）
• 禁止用户模式访问（USER = 0）

这意味着：FSBL 在此地址运行时，拥有最高权限，可自由配置系统寄存器（如 RCC、SYSCFG）、初始化外设（如 QSPI、FMC）、甚至修改 MPU 自身配置。但更重要的是，BootROM 在跳转前已关闭所有中断（FAULTMASK=1, PRIMASK=1），并清空 I-Cache/D-Cache。FSBL 的第一条指令必须是__set_MSP()设置主堆栈指针，否则任何函数调用或中断都将导致 HardFault。

; FSBL startup assembly snippet (typical) .section .text.reset, "ax", %progbits .global _start _start: ldr r0, =0x34180400 ; Load MSP value (top of SRAM2 stack) msr msp, r0 bl SystemInit ; Call C system init (clocks, etc.) ldr r0, =main bx r0

这段汇编之所以能 work，完全依赖 BootROM 已完成的底层准备：SRAM2 已供电、时钟已使能、MPU 已设为宽松模式、向量表偏移已设为 0x34180000。FSBL 的main()函数，本质上是在 BootROM 构建的“安全沙箱”中获得的第一个用户级执行机会。

3. FSBL：从「被搬运者」到「主权接管者」，它如何完成内存控制权的和平移交

FSBL 在 STM32N6 中的角色，远超传统 MCU 的 bootloader。它不是简单地“把 APP 拷过去然后跳转”，而是一个具备完整系统管理能力的微型操作系统内核：它要重新配置内存映射、重置外设状态、建立新的异常向量表、甚至动态调整 MPU region 来适配不同启动模式（Load&Run vs XiP）。它的核心任务只有一个：在 BootROM 建立的信任基座上，构建一个可扩展、可验证、可调试的第二阶段执行环境。

3.1 FSBL 的三种启动范式：Load&Run 与 XiP 的本质区别是「内存所有权模型」

文档图3（FSBL+Load&Run）与图4（FSBL+XiP）看似只是跳转地址不同，实则代表两种根本对立的内存管理哲学：

关键洞察：XiP 模式下，FSBL 必须完成QSPI Controller 的深度初始化，这远不止是配置时钟和引脚。以 QSPI 为例，FSBL 需执行：

• 发送0x35（Enter QPI mode）指令使 Flash 进入 Quad SPI 模式；
• 发送0xB7（Enable Continuous Read Mode）开启高速连续读；
• 配置 QSPI AHB 接口的CR寄存器，设置FTHRES=16（FIFO 阈值）、ABORT=0（禁止中止）、TCEN=1（使能 timeout）；
• 最关键的是设置DCR寄存器的CKMODE=1（QSPI clock enabled during read）和CSHT=0x07（chip select hold time）。

若这些寄存器配置有误，APP 即使跳转成功，第一条指令取指也会失败，表现为 HardFault 或随机跳转。

3.2 FSBL 的内存重映射：为什么 APP 的向量表不能留在 Flash，而必须复制到 SRAM？

在 Load&Run 模式下，FSBL 必须将 APP 的整个.vector_table段（通常 256 项，1024 字节）从 Flash 复制到 SRAM 的固定位置（如0x30000000），并调用SCB->VTOR = 0x30000000更新向量表偏移寄存器。原因在于：

• 中断响应延迟：Flash 访问延迟（~10–20 cycles）远高于 SRAM（1 cycle）。若向量表在 Flash，每次中断发生时，CPU 需额外等待 Flash 取指，导致中断延迟不可预测，违反实时性要求；
• MPU 限制：BootROM 配置的 Flash region 通常标记为XN=1（不可执行），仅 FSBL 显式配置的 XiP region 才允许执行。APP 的向量表若留在 Flash，默认不可执行；
• 调试兼容性：J-Link/GDB 调试器依赖向量表在 RAM 中才能正确解析中断服务例程地址。若向量表在 Flash，monitor reset halt后无法停在 reset handler。

// Typical FSBL vector table copy logic extern const uint32_t __isr_vector_start__; // Linker symbol: start of APP vector table in Flash extern const uint32_t __isr_vector_end__; // Linker symbol: end of APP vector table extern uint32_t _estack; // Linker symbol: top of SRAM stack void fsbl_copy_vector_table(void) { uint32_t *src = (uint32_t*)&__isr_vector_start__; uint32_t *dst = (uint32_t*)0x30000000; uint32_t len = (uint32_t)&__isr_vector_end__ - (uint32_t)&__isr_vector_start__; for (uint32_t i = 0; i < len/4; i++) { dst[i] = src[i]; } // Update VTOR to point to copied table SCB->VTOR = 0x30000000; }

这段代码必须在 FSBL 的SystemInit()之后、跳转 APP 之前执行。若遗漏，APP 的中断将全部指向 BootROM 的默认 handler（通常为Infinite_Loop），导致串口无响应、定时器不触发等“静默失败”。

3.3 FSBL 的异常处理接管：如何防止 APP 的 HardFault 污染 BootROM 的信任上下文

FSBL 必须在跳转 APP 前，安装自己的 HardFault/SVC/PendSV handler。这不是为了“调试 APP”，而是为了隔离故障域。BootROM 的信任链只保证 FSBL 的初始加载和签名，不保证 FSBL 之后的任何行为。若 APP 触发 HardFault 且未被 FSBL 捕获，CPU 将执行 BootROM 内置的默认 Fault handler——该 handler 通常直接 halt，导致开发板彻底失联，无法 attach、无法 reset、无法 recovery。

一个健壮的 FSBL 应实现：

// Minimal HardFault handler in FSBL void HardFault_Handler(void) { __disable_irq(); // Prevent nested faults // Read fault status registers uint32_t hfsr = SCB->HFSR; uint32_t cfsr = SCB->CFSR; uint32_t bfar = SCB->BFAR; // Log fault reason via UART (if initialized) uart_printf("HF: HFSR=0x%08lx CFSR=0x%08lx BFAR=0x%08lx\r\n", hfsr, cfsr, bfar); // Optional: trigger system reset after logging NVIC_SystemReset(); }

更重要的是，FSBL 必须在跳转前显式清除所有 pending interrupt（NVIC_ICPRx）并禁用所有 NVIC channel（NVIC_ICERx），避免 APP 未初始化中断控制器时，遗留的 pending interrupt 在跳转后立即触发，导致不可预测行为。

4. 签名工具与工程实践：-hv 2.1和-hv 2.3不是版本号，而是 BootROM 的「宪法修订案」

ST 提供的STM32MP_SigningTool_CLI.exe不是一个通用签名工具，而是专为 STM32N6 BootROM 定制的「宪法解释器」。它生成的 header 不仅包含密码学信息，更编码了 BootROM 解析器的语义规则。-hv 2.1与-hv 2.3的差异，直接对应芯片不同硬件版本（Cut）中 BootROM 固件的行为变更——这就像同一部宪法，在不同司法管辖区有不同判例解释。

4.1-hv参数的本质：BootROM 解析器的「ABI 版本标识符」

-hv 2.1和-hv 2.3并非简单的数字递增，而是 BootROM 解析器的 Application Binary Interface (ABI) 版本号。每个版本定义了：

• header 结构中各字段的 offset 和 size（如signature_offset在 v2.1 是 0x400，在 v2.3 可能变为 0x420）；
• hash 计算范围（v2.1 可能 hash 整个 image，v2.3 可能排除某些 padding 字节）；
• signature 验证使用的 ECDSA curve 参数（P-256 vs P-384）；
• 对load_address和entry_point的校验严格度（v2.1 可能允许 entry_point=0，v2.3 可能强制 >0x100）。

若用 Cut2.0 芯片（ROM 内置 v2.3 解析器）烧录-hv 2.1签名的 FSBL，BootROM 会因无法识别 header 结构而直接 halt。反之亦然。这就是为什么文档强调：“Cut1.1执行：… -hv 2.1 … Cut2.0执行：… -hv 2.3”。

4.2 签名流程的原子性：为什么-nk（no keys）选项是安全的，且不可省略

-nk参数常被误解为“不签名”，实则意为“使用 ST 内置的默认密钥对（而非用户提供的私钥）”。STM32N6 的 BootROM 中硬编码了 ST 的 ECDSA 公钥（对应私钥由 ST 严格保管），-nk指示 SigningTool 使用该私钥生成 signature。这是 ST 官方 SDK 的标准流程，确保所有开发板使用同一信任根。

若省略-nk，SigningTool 会尝试读取用户指定的 key file，若不存在则报错；若存在，生成的 signature 将无法被 BootROM 验证（因公钥不匹配），导致启动失败。因此-nk不是可选优化，而是信任链成立的必要条件。

4.3 签名验证的离线模拟：如何在烧录前确认 header 有效性？

与其反复烧录-复位-失败，不如在 PC 端模拟 BootROM 的验证逻辑。以下 Python 脚本可验证FSBL-trusted.bin是否满足 v2.1 header 要求：

# validate_fsbl_header.py import sys import hashlib import ecdsa def validate_header(bin_path): with open(bin_path, 'rb') as f: data = f.read() if len(data) < 1024: print("ERROR: File too small (<1024 bytes)") return False # Parse header fields (v2.1 layout) magic = int.from_bytes(data[0:4], 'little') if magic != 0x53544D32: print(f"ERROR: Invalid magic 0x{magic:08x}, expected 0x53544D32") return False hv = int.from_bytes(data[4:8], 'little') if hv != 0x00020001: # 2.1 print(f"ERROR: Invalid header version 0x{hv:08x}, expected 0x00020001") return False img_size = int.from_bytes(data[8:12], 'little') if len(data) < 1024 + img_size: print(f"ERROR: File size {len(data)} < 1024 + img_size {img_size}") return False # Calculate SHA-256 of (header without hash/signature + image body) # v2.1: hash covers [0:1024-32-256] + [1024:1024+img_size] hash_region = data[0:1024-32-256] + data[1024:1024+img_size] expected_hash = hashlib.sha256(hash_region).digest() actual_hash = data[1024-32-256:1024-256] if actual_hash != expected_hash: print("ERROR: SHA-256 hash mismatch") return False print("SUCCESS: Header validation passed") return True if __name__ == "__main__": if len(sys.argv) != 2: print("Usage: python validate_fsbl_header.py <FSBL-trusted.bin>") sys.exit(1) validate_header(sys.argv[1])

运行python validate_fsbl_header.py FSBL-trusted.bin，若输出SUCCESS，则 90% 概率可被 BootROM 接受。这是比 CubeProgrammer 烧录更快的验证闭环。

5. 开发避坑指南：那些让 STM32N6 启动失败的「血泪经验」，每一条都来自真实翻车现场

开发 STM32N6 FSBL 时，80% 的问题并非逻辑错误，而是对 BootROM 与 FSBL 交互细节的误判。以下是某开发者在调试 UART_HyperTerminal_IT demo 时踩过的 5 个典型坑，按「现象 → 原因 → 解决」结构整理，每一条都经 CubeProgrammer 和 J-Link 实测验证。

5.1 现象：CubeProgrammer 烧录成功，但复位后无任何串口输出，ST-Link 无法连接

原因：烧录时使用了 hex 文件，且未指定-addr 0x70000000。IAR 默认将代码链接到0x30000000（SRAM），hex 文件中地址记录为0x30000000，CubeProgrammer 将其烧录到 Flash 的0x30000000地址（超出 Flash 范围，实际写入 Flash 起始处0x70000000的是无效数据）。BootROM 在0x70000000读到乱码，magic 不匹配，直接 halt。
解决：烧录 hex 文件时，必须在 CubeProgrammer 的 “Download” 选项卡中勾选 “Specify address” 并填入0x70000000；或统一使用 bin 文件烧录（-w FSBL-trusted.bin 0x70000000）。

5.2 现象：Dev mode 下调试正常，Flash boot 模式下串口输出乱码（如???）

原因：FSBL 初始化了 QSPI Flash，但未正确配置 UART 的时钟源。STM32N6 的 UART1 时钟可选 HSI48、PLL2_Q 或 SYSCLK。在 Dev mode，SYSCLK 可能为 64MHz；在 Flash boot，FSBL 可能将 SYSCLK 切换为 120MHz，但 UART 波特率寄存器（BRR）仍按 64MHz 计算，导致实际波特率偏差 >5%，通信失败。
解决：在 FSBL 的SystemInit()中，明确调用HAL_RCCEx_PeriphCLKConfig()配置 UART 时钟源，并在MX_USART1_UART_Init()前重新计算 BRR 值，或使用HAL_UART_Init()的自动重配置功能。

5.3 现象：FSBL 烧录成功，但跳转 APP 后立即 HardFault，CFSR=0x01000000（INVPC）

原因：APP 的链接脚本（.ld）中ENTRY(_start)指向的_start符号位于 Flash 地址（如0x70000100），但 FSBL 的memcpy()只复制了.text和.rodata，未复制.vector_table到 SRAM。SCB->VTOR仍为 0，CPU 从0x00000000取向量表，第一条指令取到 BootROM 的非法地址。
解决：在 APP 的链接脚本中，将.vector_table段显式分配到 SRAM（> RAM），或在 FSBL 中添加fsbl_copy_vector_table()函数并确保在跳转前调用。

5.4 现象：XiP 模式下 APP 启动后，QSPI Flash 读取返回全 0xFF

原因：FSBL 配置 QSPI 时，未发送0x35（Enter QPI）指令，或发送后未等待 Flash 状态寄存器WIP=0（Write In Progress）。QSPI 控制器处于 SPI 模式，无法解析 Quad 指令，导致所有读操作失败。
解决：在 FSBL 的 QSPI 初始化函数中，添加完整的状态轮询：

// After sending 0x35 command while (qspi_read_status_reg() & 0x01) { // Wait for WIP=0 __NOP(); }

5.5 现象：Cut2.0 开发板烧录-hv 2.1签名的 FSBL，CubeProgrammer 报错 “Authentication failed”

原因：BootROM v2.3 解析器拒绝识别 v2.1 header 结构，直接返回认证失败。这不是签名错误，而是 ABI 不兼容。
解决：严格按文档区分 Cut 版本。查询芯片丝印（如N6570-DK-CUT20），下载对应版本的 STM32CubeIDE 和 SDK，并使用STM32MP_SigningTool_CLI.exe -hv 2.3重新签名。

6. 设计取舍的终极思考：为什么 STM32N6 不把 FSBL 直接固化进 ROM？以及，我从此养成了一个强迫症习惯

STM32N6 的 BootROM 只做最精简的验证与搬运，把 FSBL 的全部逻辑留给用户实现，这个设计看似增加了开发复杂度，实则蕴含三层深意：

第一层是安全弹性。固化 FSBL 意味着所有安全策略（如密钥管理、安全启动、固件更新）被硬编码，一旦发现漏洞无法修补。而将 FSBL 作为可更新镜像，厂商可在后续发布中升级签名算法、增加 Secure Boot 检查项、集成 TEE（Trusted Execution Environment）初始化逻辑，无需改芯片。

第二层是生态开放。FSBL 是用户代码与硬件之间的第一道胶水。它必须适配不同的 Flash 类型（QSPI NOR、OctoSPI、HyperFlash）、不同的调试协议（SWD、JTAG）、不同的安全模块（AES accelerator、PKA）。若固化，ST 就得为每种组合预编译一个 ROM 版本，导致芯片成本飙升。而让用户自己写 FSBL，等于把适配工作下沉到生态伙伴，ST 只需提供 SigningTool 和 HAL 驱动。

第三层是调试可控性。BootROM 是黑盒，无法 debug。而 FSBL 运行在 SRAM，可 full SWD 调试。当启动失败时，开发者可以 attach 到 FSBL，单步执行qspi_init()、检查SCB->VTOR、观察memcpy()后的 SRAM 内容——这种可观测性，是固化 ROM 永远无法提供的。

正因如此，我从此养成了一个强迫症习惯：每次新建 STM32N6 工程，第一件事不是写main()，而是打开STM32MP_SigningTool_CLI --help，确认当前 SDK 版本对应的-hv参数；第二件事是写一个最小fsbl_header_check()函数，放在 FSBL 的main()开头，用printf输出SCB->VTOR、__get_MSP()、*(uint32_t*)0x70000000（magic）三个值，确保 BootROM 真正把控制权交到了我手上。只有看到串口打出VTOR=0x30000000, MSP=0x34180400, MAGIC=0x53544D32，我才敢继续往下写 UART 初始化。

这个习惯让我少走了三个月弯路。希望帮到你。

本文还有配套的精品资源，点击获取