STM32 on Zesean 的博客

冷阴极 X 射线源球壳钛合金焊缝检测装置（下位机）

Tue, 01 Sep 2026 22:30:00 +0800

项目概述

国家重点研发项目子课题：冷阴极 X 射线源球壳钛合金焊缝检测装置的运动控制系统（下位机部分）。

装置通过 X 射线源与平板探测器沿弧形轨道协同扫查，对球壳钛合金焊缝成像检测。下位机负责对 X 射线源、探测器的协同控制与远程控制：配合 QT 上位机调整射线源与探测器的速度与动作，完成单段焊缝、截面焊缝两种检测模式，并实时上报系统状态。

系统组成

flowchart TB
 PC["QT 上位机"] <-->|"RS485 自定义协议帧
UART 中断+DMA · 字节状态机 · 环形缓冲"| MCU["STM32F429 下位机
FreeRTOS 多任务"]
 MCU -->|"Modbus RTU + CRC16"| SERVO["禾川伺服电机驱动器"]
 SERVO --> AXIS["弧形轨道多电机协同"]
 AXIS --> DEV["X 射线源 + 平板探测器"]

整机实拍：左侧为提升立柱与弧形齿轮轨道，右侧为探测器载滑车，地面为多路禾川伺服驱动器与供电线缆。

软件分层与模块

软件分为两层：APP 应用层承载对外协议、运动语义与任务调度；驱动层提供寄存器级能力（Modbus 协议模板与 CRC、电机寄存器配置序列、OLED/菜单/按键、FLASH 参数存储）。

模块	职责
`app_conf.h`	全部可调参数集中管理：协议常量、超时、限幅、软限位、任务栈与优先级、RS485 开关
`host_proto.h/.c`	RS485/USART6 二进制协议栈：TX DMA + 环形缓冲 + 组包 CRC；RX IDLE+DMA + 环形缓冲 + 字节状态机解析；命令分发回调；心跳时间戳；收发统计
`motion_api.h/.c`	统一运动控制接口：轴状态机（IDLE/READY/MOVING/FAULT）、方向（速度符号）/速度（±3000 限幅）/动作时序（松闸稳定→运动→清速减速→抱闸）、编码器事务三重校验、软限位、安全关断收敛入口、故障复位
`dev_task.h/.c`	四大逻辑任务：motionTask（动作执行+ACK）、statusTask（50ms 状态轮询+100ms 状态帧）、monitorTask（心跳超时/故障沿上报/IWDG 喂狗点）、装配函数 `APP_TasksInit()`

软件架构

数据流（下行指令 → 上行状态）

flowchart TB
 PC["上位机"] -->|"A5 5A 协议帧"| RX["USART6 RX
IDLE 中断 + DMA 批量入环形缓冲"]
 RX --> PARSE["parseTask（AboveNormal）
7 态字节状态机 + CRC16 查表校验"]
 PARSE -->|"CRC 通过"| Q["motionQueue
8 深消息队列削峰"]
 Q --> MOTION["motionTask（High）
动作时序执行 + ACK 上行"]
 MOTION -->|"轴级互斥锁串行化"| MB["UART4/5 RS485
Modbus RTU"]
 MB --> DRIVE["禾川伺服驱动器
速度环 + 电流环硬件闭环"]
 DRIVE --> AXIS["弧形轨道双轴电机"]

 STATUS["statusTask（Normal · 50ms）
编码器轮询 + 软限位检查"] --> MB
 STATUS -->|"100ms 状态帧 0x82
TX 环形缓冲 + DMA"| PC
 MON["monitorTask（Normal · 100ms）
心跳超时 / 故障沿 / IWDG"] -->|"SafeShutdown + 0x8F 上报"| MOTION

任务划分

任务	CMSIS 优先级	栈	阻塞点	职责
parseTask	AboveNormal	2KB	线程标志（50ms 超时）	协议解析（状态机+CRC）
motionTask	High	2KB	消息队列（100ms 超时）	动作执行 + 定时动作截止判定
statusTask	Normal	2KB	osDelay(50)	编码器轮询 + 状态反馈
monitorTask	Normal	1.5KB	osDelay(100)	心跳超时/故障沿/安全关断触发
oledShowMenuTask	Low	512B	事件标志	菜单显示（按键扫描定时器 10ms）
defaultTask	Normal	512B	osDelay(1000)	LED 心跳

两个关键的执行体设计：

协议解析与动作执行分离：解析出指令后经 8 深消息队列投递给 motionTask 按序执行，队列削峰保证解析节奏不受动作耗时拖累；
编码器轮询放在任务而非软件定时器中：定时器回调与任务可能并发访问同一 Modbus 通道，统一到任务上下文并配合轴级互斥锁后，「请求-应答」事务被彻底串行化。

任务优先级设计依据

优先级不是按“功能重要性”排的，而是按三条工程准则：

截止期与后果：动作执行（清速/抱闸/安全关断）有硬时序且后果不可逆 → 最高应用优先级；
阻塞特性：事件驱动型任务平时全部阻塞在同步原语上，高优先级只影响唤醒延迟，不产生 CPU 争抢；
依赖方向：数据流上游不能被下游长时间阻塞（parse 喂 motion 的队列；status 的编码器数据被 motion 的轴锁依赖）。

完整优先级谱系（NVIC 中断优先级与任务优先级是两套量纲，勿混）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


NVIC 中断 (任何 ISR 可抢占任何任务)
 ├─ UART4/5/6/8 抢占优先级=5（恰好等于 FreeRTOS 可调用 API 的阈值，
 │ ISR 内允许 FromISR API；只做批量入环形缓冲 + flagsSet，µs 级）
任务 (FreeRTOS 原生优先级，抢占式 + 同级时间片轮转)
 ├─ 38 High motionTask ← 安全动作的执行权最高
 ├─ 31 AboveNormal parseTask ← 必须高于周期型任务，否则状态轮询可推迟命令解析
 ├─ 23 Normal statusTask / monitorTask / defaultTask
 ├─ 8 Low oledShowMenuTask（人机界面，空闲余量处理）
 ├─ 2 Timer Service（按键扫描定时器，CubeMX 默认值）
 └─ 0 Idle

几个关键取舍：

为什么 motion(38) > parse(31)：命令队列已削峰（8 深），解析晚 1–2ms 不影响正确性；反之若 parse 更高，解析长帧期间到达的停止/安全命令会被推迟执行——安全动作的执行权高于协议的解析权。
status/monitor 同级 Normal：两者都是周期型软实时（50ms/100ms），判定窗口（软限位/心跳 500ms）远大于调度延迟；它们持锁时间短（单次 Modbus 事务约 6ms），motion 高优先级被轴锁阻塞时由互斥量优先级继承临时提升持锁任务，消除优先级反转。
关中断快照 vs 互斥量：跨任务读轴状态用 __disable_irq() 短临界区（µs 级、无反转风险）；锁只用于必须串行化的 Modbus 事务（同一 UART 的请求-应答配对）。
一个已知限制：定时器守护任务优先级为 CubeMX 默认值 2，低于所有应用任务——当前成立的条件是所有任务都有周期阻塞点，定时器总能在间隙运行；若未来把安全逻辑放进软件定时器（如限位去抖），必须提高该优先级。
Realtime(47) 刻意留空：为硬实时扩展预留（5–20ms 节拍的位置环、限位 EXTI 的紧急处理链）。

轴状态机

stateDiagram-v2
 [*] --> IDLE
 IDLE --> READY: InitAll（伺服参数+原点捕获+松闸）
 READY --> MOVING: SetSpeed / MoveTimed
 MOVING --> READY: Stop（清速→等减速→抱闸）
 READY --> FAULT: Safe_Shutdown（异常保护）
 MOVING --> FAULT: Safe_Shutdown
 FAULT --> READY: FaultReset（重初始化+重捕获原点+松闸）

任何异常都收敛到单一安全关断入口 MOTION_SafeShutdown()：清速 → 等 150ms（驱动器 100ms 减速斜坡完成，避免高速抱闸冲击）→ 断抱闸继电器 → 锁定 FAULT + 故障码 → monitorTask 沿检测上报。恢复必须显式故障复位指令。

上位机帧协议

帧格式

1
2
3
4


┌──────┬──────┬─────┬──────┬─────────────┬─────────────┬──────────────┐
│ 0xA5 │ 0x5A │ SEQ │ LEN │ CMD │ DATA[LEN] │ CRC16_LO/HI │
└──────┴──────┴─────┴──────┴─────────────┴─────────────┴──────────────┘
 帧头1 帧头2 序号 载荷长 命令字 0~64B 小端 查表 CRC16，低字节先

双帧头 A5 5A：误同步率 1/65536；A5/5A 位翻转丰富，示波器上可辨；
SEQ 序号：下行主机自增（ACK 回显 → 去重/丢帧检测），上行设备独立自增；
LEN 显式变长：状态机据此收数，天然支持命令扩展；
CRC16 覆盖 SEQ..DATA（不含帧头与自身），算法与 Modbus 完全一致（同一张查表），全协议栈一套 CRC；
帧开销 7 字节；载荷中可能出现假帧头，由 CRC 兜底丢弃（更高可靠场景可选 COBS 变长编码）。

命令集

CMD	方向	载荷	语义
0x01	下行	轴号 + 开关	抱闸控制
0x02	下行	轴号 + rpm(int16)	速度指令（符号=方向，±3000 限幅）
0x03	下行	轴号 + rpm + 时长(100ms 单位)	定时动作（动作时序演示）
0x04	下行	轴号（0xFF=全轴）	停止
0x05	下行	seq 回显	心跳（200ms 周期，不回 ACK）
0x06	下行	轴号（0xFF=全部）	故障复位
0x07	下行	无	立即请求状态帧（回 0x82）
0x81	上行	回显命令/序号 + status	命令应答（OK/BUSY/REJECT/BAD_ARG）
0x82	上行	状态字×2 + 双轴速度 + 故障码	周期状态帧（100ms）
0x8F	上行	故障码 + 轴号 + 保留	故障上报（故障沿触发一次）

实例帧（CRC 实算，可直接用于联调）

帧	字节
轴1 速度 -500rpm	`A5 5A 01 03 02 01 FE 0C 55 D7`
轴2 800rpm 转 3.0s	`A5 5A 02 04 03 02 20 03 1E FD CE`
心跳	`A5 5A 03 01 05 5A D2 CB`
状态帧（READY/MOVING，sp1=1500，fault=0x0001）	`A5 5A 10 08 82 01 02 DC 05 00 00 01 00 97 A8`
故障帧（驱动器无应答，轴1）	`A5 5A 11 05 8F 02 00 01 00 00 E2 F4`

解析鲁棒性（7 态状态机 + 三重防护）

LEN > 64 → 丢弃回找头（防超长帧打爆缓冲）；
帧内字节间隔 > 50ms → 强制回找头（防半帧卡死）；
CRC 失败 → 丢当前帧回找头（假同步自愈）；RX 环满 → 丢最新并计数上报统计。

接收链路硬件侧使用 UART 中断 + DMA 不定长接收，以 IDLE 总线空闲事件判帧：

1
2


__HAL_UART_ENABLE_IT(&huart6, UART_IT_IDLE);
/* 帧长 = 接收缓冲区大小 - __HAL_DMA_GET_COUNTER(&hdma_usart6_rx) */

ISR 只做批量搬移入环形缓冲（SPSC 免锁）+ 置线程标志，解析全部在 parseTask 完成——ISR 保持极短是实时性的关键：若在中断里做逐字节处理甚至打印，9600 波特率下一帧即可阻塞几十 ms。

统一运动控制 API

对上层屏蔽多电机与 Modbus 细节，全部运动能力收敛为一组 MOTION_* 接口：

API	语义
`MOTION_InitAll()`	伺服参数写入 + 原点捕获 + 松闸（任务上下文）
`MOTION_SetSpeed(ax, rpm)`	方向=符号；自动先松闸再设速
`MOTION_MoveTimed(ax, rpm, dur)`	速度 + 截止期（定时动作）
`MOTION_Stop(ax)`	清速 → 150ms 减速等待 → 抱闸
`MOTION_Brake(ax, open)`	手动抱闸（运动中拒绝）
`MOTION_Tick()`	定时动作到期判定（100ms 粒度）
`MOTION_PollFeedback()`	双轴编码器轮询 + 无应答计数 + 软限位
`MOTION_GetSnapshot(ax, &s)`	状态/速度/位置/故障原子快照
`MOTION_SafeShutdown(ax, fault)`	安全关断唯一入口
`MOTION_FaultReset(ax)`	FAULT → READY：重初始化 + 重捕获原点 + 松闸

底层由一组寄存器级驱动接口支撑：

1
2
3
4


Motor_Init(MOTOR1); // 初始化：Modbus 链路建立 + 驱动器寄存器配置
openMotor(MOTOR1); // 电机使能
speed_set(MOTOR1, speed); // 速度模式设定：负速度转补码写入，±3000rpm 软件限幅
closeMotor(MOTOR1); // 去使能（配合抱闸继电器安全停机）

Modbus RTU 驱动器接口

功能码	用途
0x03	读保持寄存器（状态/速度回收）
0x06	写单寄存器（速度设定等）
0x10	写多寄存器（批量参数下发）

帧结构：地址(1B) + 功能码(1B) + 数据(NB) + CRC16(2B，低字节在前)
CRC16 参数：多项式 0x8005（反射 0xA001）、初值 0xFFFF，实现查表法与逐位法两种等价算法——上位机协议栈的 CRC 直接复用同一张表
实例帧：01 06 03 03 05 DC → CRC = 7B 47
错误应答识别：功能码 + 0x80
编码器读事务做功能码 + 长度 + CRC 三重校验，连续无应答即触发单轴安全关断

异常保护体系

保护	触发条件	动作
心跳丢失	500ms 无任何合法帧（首帧后生效）	全轴 SafeShutdown + 0x8F 上报
驱动器失联	连续 3 次编码器读无应答/校验失败	单轴 SafeShutdown
软限位	位置超出 ±170°（可配）且运动中	单轴 SafeShutdown
硬限位	EXTI 接口预留（硬件常闭开关已具备）	后续接入 SafeShutdown 链
CRC 错帧	校验失败	丢帧 + 收发统计
IWDG	喂狗点已置于 monitorTask（启用为编译开关）	复位兜底
抱闸 failsafe	硬件特性：断电即抱死	物理兜底

关于伺服三环控制的工程结论

电流环/速度环/位置环要不要在 MCU 里做？——不需要，这是伺服系统的标准级联结构：

位置环（软件，按曲线节拍）→ 速度环（驱动器硬件闭环）→ 电流环（驱动器硬件闭环，µs 级带宽）；
若强行在 MCU 做三环：RS485 半双工往返 + RTOS 任务抖动，内环带宽根本撑不起来，反而劣化性能；
本项目 MCU 只做位置外环：协议与运动接口预留位置指令扩展，速度/电流环交给禾川驱动器。

轨迹跟踪业务层的实现方案：双电机按 FLASH 中的 1000 点位置/速度曲线做 S 曲线协同跟踪——位置 PID + 速度前馈 + 双电机交叉耦合补偿，位置环输出直接写驱动器速度寄存器；上位机经 LoRa 链路完成曲线分块下传（块号 ACK 隐含重传）、误差曲线回读、前馈/耦合系数在线整定与点动控制；限位开关走 EXTI 硬件链路。

已知限制与后续项

驱动器应答等待仍为固定 5ms 盲等，改进方向是信号量 + 超时；
IWDG 未启用（喂狗点与启用步骤已就位，编译开关打开即用）；
硬限位 EXTI 尚未接入软件保护链（常闭开关硬件与 EXTI 驱动已具备，接入方案：ISR 直接抱闸 + 通知任务走 SafeShutdown）；
USART6 波特率 9600，协议帧建议提升到 115200；
printf 复用上位机串口，正式版应以编译开关关闭或改用独立调试口；
位置闭环当前为速度模式的接口预留，轨迹跟踪按上文 S 曲线方案扩展。

项目状态

下位机软件已完成「RS485 协议栈 + 统一运动接口 + 四大逻辑任务 + 多级异常保护」的完整架构实现；驱动层经整机联调实测，Modbus 通信、双轴运动控制、上位机链路稳定工作，支撑完成单段焊缝与截面焊缝检测流程。

STM32 BootLoader 学习笔记

Sat, 30 Aug 2025 14:00:00 +0800

BootLoader 学习

硬件：

stm32f407(嘉立创天空星)
HC-05蓝牙模块软件：
暂时使用python简陋演示功能

为什么要有bootloader

类似于电脑的boot，可以让我们很方便的去重装系统，可以用u盘重装系统，可以在线重装系统等
可以把一些固定参数放到bootloader里，比如屏幕亮度，初始参数等等，可以专注于APP的开发

前置知识

单片机组成

电脑组成 stm32内部，与电脑组成类似，主要强调：

片内Flash：相当于电脑硬盘
嵌入式 SRAM：相当与电脑内存条

你需要知道：

嵌入式SRAM是被映射在$0x2000 0000$上的
嵌入式flash是被映射在$0x0800 0000$

stm32启动流程

STM32微控制器从上电或复位到执行你编写的 main() 函数 之前，会经历一系列由硬件和启动代码（通常是汇编语言编写的）完成的初始化步骤

下面是 STM32 从上电到进入 main() 函数的详细过程：

一、硬件复位与启动模式选择

1. 上电复位 (POR) 或硬件复位

当STM32芯片上电或者复位引脚（NRST）被置为低电平并释放时，微控制器会进入复位状态。在复位期间，所有内部寄存器会被设置为预设的初始值，确保系统处于一个确定的、已知的状态。

2. 选择启动模式 (BOOT Pins)

CPU内核在复位结束后，首先会采样特定的启动引脚（如 BOOT0 和 BOOT1，具体名称和数量可能因型号而异）。这些引脚的状态决定了微控制器从哪个存储器空间开始执行代码：

主闪存启动 (Main Flash Memory)：最常用的模式，运行用户编写的程序。
系统存储器启动 (System Memory)：运行内置的 Bootloader，用于通过串口、USB等接口烧录程序。
SRAM 启动 (Embedded SRAM)：运行驻留在SRAM中的代码，不常用。通常，在运行用户程序时，会配置为从主闪存启动。

二、Cortex-M 内核的初始寻址

STM32 的核心是 Cortex-M 系列内核（如 M0、M3、M4、M7），它们遵循一个标准化的启动流程，这部分是由硬件自动完成的。

3. 读取中断向量表

微控制器根据启动模式，确定中断向量表的起始地址（在主闪存启动模式下，通常是 0x0800 0000）。中断向量表是存储了各种异常和中断服务程序入口地址的表格。

4. 初始化栈指针 (SP)

CPU 从向量表的第一个 32 位字（地址 Boot_Address + 0x00）中读取初始的 主栈指针 (MSP) 的值。这是程序中栈区的最高地址，用于存储局部变量、函数调用返回地址等。

5. 设置程序计数器 (PC)

CPU 从向量表的第二个 32 位字（地址 Boot_Address + 0x04）中读取 复位处理程序（Reset_Handler）的地址，并将这个地址加载到 程序计数器 (PC) 中。 至此，硬件初始化完成，程序控制权正式移交给 Reset_Handler。

三、执行启动文件代码 (`Reset_Handler`)

Reset_Handler 是由编译器和芯片厂商提供的一个汇编语言函数，通常位于项目中的 startup_stm32xxx.s 文件（即启动文件）中。它的任务是为C/C++程序的运行准备好环境，包括内存、时钟和库函数等。

6. 调用 `SystemInit()`

Reset_Handler 做的第一件大事是调用 SystemInit() 函数（通常在 system_stm32xxx.c 文件中）。该函数主要完成：

配置系统时钟：设置主时钟源、PLL 倍频等，将系统时钟配置到所需的工作频率（但此时还不涉及用户外设时钟）。
配置存储器：如设置 Flash 访问等待周期等。

7. 初始化 RAM 中的数据段

初始化 .data 段：.data 段存储了已初始化的全局变量和静态变量。这些变量的初始值存储在 Flash 中，Reset_Handler 会将这些值从 Flash 复制到 RAM 中。
初始化 .bss 段：.bss 段存储了未初始化的全局变量和静态变量。C 语言标准要求它们在程序开始时必须被清零。Reset_Handler 会将 .bss 段在 RAM 中的区域清零。

8. 调用 C 库初始化函数

对于标准 C/C++ 环境，Reset_Handler 还会调用 C 库的初始化函数（例如 __libc_init_array），用于：

初始化 C 运行时环境。
调用 C++ 程序的静态构造函数（如果你的代码中有使用）。

9. 跳转到 `main()`

在完成所有必要的硬件和软件环境准备后，Reset_Handler 的最后一步就是执行一条跳转指令，调用用户编写的 main() 函数。代码段

; 假设这是 Reset_Handler 的最后几行伪汇编代码
; ...
BL SystemInit ; 调用系统时钟初始化函数
BL __libc_init_array ; 调用 C 库初始化函数
LDR R0, =main ; 将 main 函数地址加载到 R0
BX R0 ; 跳转到 main 函数执行

至此，STM32 终于进入了你的应用程序，开始执行用户代码。

总结流程图

上电后检查boot引脚的高低决定从哪启动（在哪寻找代码）
读取代码(编译后的2进制文件)的第一个字(主堆栈的地址)，（工厂的工作地点）
寻找第二个字以运行到main();

步骤	执行者	动作描述	目标
1	硬件/CPU	上电复位 (POR)	强制所有硬件到初始状态。
2	硬件/CPU	检查 BOOT 引脚	确定代码的启动位置（如主 Flash）。
3	硬件/CPU	读取向量表	确定 SP 和 PC 的初始值。
4	硬件/CPU	设置初始 SP/PC	初始化主栈指针，跳转到 `Reset_Handler`。
5	启动文件	调用 `SystemInit()`	配置系统时钟和 Flash 等基础硬件。
6	启动文件	初始化数据段	从 Flash 复制 `.data` 到 RAM，将 `.bss` 段清零。
7	启动文件	调用库初始化	初始化 C 运行时环境和静态构造函数。
8	启动文件	调用 `main()`	进入用户应用程序的起点。

问题：

Question1为什么启动后需要先找到中断向量表呢，很重要吗?

Question2:堆栈是用来干嘛的，为什么要先初始化它，不初始化会怎么样

Question3：为什么会映射成0x08000000呢

简单跳转代码

使用O3优化可以减小boot大小 fromelf –bin -o “$L@L.bin” “#L

Boot

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


typedef void (*pFunction)(void);

void JumpToApplication(void) {
 // 1. 检查应用程序地址是否有效
 // 应用程序的栈顶地址位于其起始地址的第一个字
 if (((*(__IO uint32_t*)APP_ADDRESS) & 0x2FFE0000) == 0x20000000) {
 // 2. 将中断向量表重定向到应用程序地址
 SCB->VTOR = APP_ADDRESS;

 // 3. 获取应用程序的栈顶地址和复位处理函数地址
 pFunction app_reset_handler = (pFunction)(*(__IO uint32_t*)(APP_ADDRESS + 4));
 __set_MSP(*(__IO uint32_t*)APP_ADDRESS);

 // 4. 跳转到应用程序
 app_reset_handler();
 }
}

APP

随便，但是：

问题

question1 SCB是什么：

远程下载讲解

注意事项：HC-05的VCC接3V3，实测5V无法使用蓝牙模块只有在通信状态才会显示已连接蓝牙，打不开蓝牙串口参考：HC05和电脑蓝牙通讯 HC05-python-stm32的波特率必须都设置为同样的速率，我这里为9600

蓝牙模块讲解

总结：当成远程串口用就行

常用AT指令

波特率为38400

指令	返回	意义
AT	ok	检测固件是否可用
AT+RESET	ok	模块软件复位
AT+VERSION?	+VERSION:<Param> OK	获取固件版本
AT+NAME=name	ok	设置模块名字
AT+NAME?	+NAME:<Param> OK	返回模块名字
AT+PSWD=“passwd”	OK	设置模块密码
AT+PSWD?	+PSWD:<Param> OK	获取模块密码
AT+UART=115200,0,0	ok	设置通信时的波特率
AT+UART?	+UART:<Param1>,<Param2>,<Param3> OK	获取串口参数

模块指示灯标志

定时闪两下：已经连接蓝牙，处于通信状态
快闪：未连接
慢闪：工作模式，可使用AT指令调整参数（进入：保持按键按下，通电后松开按键即可）

测试流程

先进入工作模式，使用AT检查是否可用，
设置模块名字：AT+NAME=MyBluetooth
获取密码：AT+PSWD?
查看波特率：AT+UART?

嵌入式Flash操作

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


void Flash_Erase_App(void)
{
 FLASH_EraseInitTypeDef EraseInit;
 uint32_t PageError;
 // 解除Flash保护
 HAL_FLASH_Unlock();

 // F407: sector2(扇区2) = 0x08008000 开始
 EraseInit.TypeErase = FLASH_TYPEERASE_SECTORS;
 EraseInit.Sector = FLASH_SECTOR_2;
 EraseInit.NbSectors = 6; // 到 sector7(扇区7)
 EraseInit.VoltageRange = FLASH_VOLTAGE_RANGE_3;

 if (HAL_FLASHEx_Erase(&EraseInit, &PageError) != HAL_OK) {
 // 错误处理
 }
 // 开启保护
 HAL_FLASH_Lock();
}

HAL_StatusTypeDef Flash_Write(uint32_t addr, uint8_t *data, uint32_t len)
{
 HAL_StatusTypeDef status;
 HAL_FLASH_Unlock();

 for(uint32_t i=0; i<len; i+=4) {
 uint32_t word = *(uint32_t*)(data+i);
 status = HAL_FLASH_Program(FLASH_TYPEPROGRAM_WORD, addr+i, word);
 if(status != HAL_OK) break;
 }

 HAL_FLASH_Lock();
 return status;
}

主要逻辑

固件发送与接收

Bootloader代码逻辑

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


void Bootloader_Update(void)
{
 uint8_t cmd;
 uint8_t buf[256];
 uint32_t addr = APP_ADDR;

 Flash_Erase_App();

 while(1)
 {
 HAL_UART_Receive(&huart1, &cmd, 1, HAL_MAX_DELAY);

 if(cmd == CMD_DATA) {
 uint16_t len;
 HAL_UART_Receive(&huart1, (uint8_t*)&len, 2, HAL_MAX_DELAY);
 HAL_UART_Receive(&huart1, buf, len, HAL_MAX_DELAY);

 Flash_Write(addr, buf, len);
 addr += len;

 HAL_UART_Transmit(&huart1, (uint8_t*)"OK", 2, HAL_MAX_DELAY);
 }
 else if(cmd == CMD_END) {
 HAL_UART_Transmit(&huart1, (uint8_t*)"DONE", 4, HAL_MAX_DELAY);
 break;
 }
 }
}

电脑_python–发送

python要先安装pyserial跑：pip install pyserial 固件采用分批的形式发送，使用python脚本进行发送 ser = serial.Serial("COM4", 9600)这里的COM4需要改成你的com端口

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


import serial
import struct
# 初始化一个串口对象
ser = serial.Serial("COM4", 9600)

def send_data(data):
 ser.write(b"\x02") # CMD_DATA
 # 把当前数据块的长度打包成两个字节的无符号整数（小端序）。
 # 比如 len(data) = 256，那么结果是 b'\x00\x01'，开发板端可以据此知道这包数据有多长。
 ser.write(struct.pack("<H", len(data)))
 ser.write(data)
 # 阻塞读取开发板发送的信息，确保是否传递成功
 print(ser.read(2)) # OK

with open("app.bin", "rb") as f:
 while True:
 # 每次循环读取256个数据
 chunk = f.read(256)
 if not chunk:
 break
 send_data(chunk)

ser.write(b"\x03") # CMD_END
print(ser.read(4)) # DONE

stm32_蓝牙–接收

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37


#define APP_ADDR 0x08008000
#define CMD_START 0x01
#define CMD_DATA 0x02
#define CMD_END 0x03
void Bootloader_Update(void)
{
 uint8_t cmd;
 uint8_t buf[256];
 uint32_t addr = APP_ADDR;
 // 擦除老APP,准备迎接新王
 Flash_Erase_App();

 while(1)
 {
 // 堵塞接收，根据先接收到的命令决定怎么做
 HAL_UART_Receive(&huart1, &cmd, 1, HAL_MAX_DELAY);
 // 数据命令，表示接收到的是数据
 if(cmd == CMD_DATA) {
 uint16_t len;
 // 获取长度
 HAL_UART_Receive(&huart1, (uint8_t*)&len, 2, HAL_MAX_DELAY);
 // 获取内容
 HAL_UART_Receive(&huart1, buf, len, HAL_MAX_DELAY);
 // 写入内容
 Flash_Write(addr, buf, len);
 // 位移地址，准备写入后续内容
 addr += len;
 // 回应OK
 HAL_UART_Transmit(&huart1, (uint8_t*)"OK", 2, HAL_MAX_DELAY);
 }
 // 结束命令，表示接收完成，退出该函数
 else if(cmd == CMD_END) {
 HAL_UART_Transmit(&huart1, (uint8_t*)"DONE", 4, HAL_MAX_DELAY);
 break;
 }
 }
}

增加校验-CRC32

一、CRC32 是什么

CRC 全称 Cyclic Redundancy Check（循环冗余校验）。
CRC32 表示它使用的是 32位的多项式运算结果。它不是“加法求和”那种简单校验，而是用一种二进制多项式除法的思想：

把整个数据看作一个很长的二进制数；
用一个固定的“生成多项式”去做模2除法；
最后得到一个 32 位的余数；
这个余数就是 CRC 校验码。

🧠 模2除法：相当于普通除法，但所有加减都用“异或（XOR）”。

二、CRC32 的作用

CRC32 不是用来“防黑客”或“加密”的，而是为了 检测传输或存储过程中的错误。例如：

你通过串口发送 100KB 的固件；
中途某一字节丢了、翻转了；
STM32 收到的文件计算出的 CRC 不等于原始文件的 CRC；
→ 说明传输错误，不执行更新。可以检测出几乎所有单比特错误、突发错误，非常可靠。

电脑端-python增加校验

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46


import serial
import struct
import binascii
from tqdm import tqdm # pip install tqdm

# 打开串口
ser = serial.Serial("COM4", 9600, timeout=2)

def send_data(data):
 # 发送数据包
 ser.write(b"\x02") # CMD_DATA
 ser.write(struct.pack("<H", len(data))) # 长度
 ser.write(data) # 数据本体
 resp = ser.read(2) # Bootloader 回复 OK
 if resp != b"OK":
 raise Exception("Bootloader写入失败，返回: %s" % resp)

def send_end(crc32, total_size):
 # 通知 Bootloader 固件结束 + CRC
 ser.write(b"\x03") # CMD_END
 ser.write(struct.pack("<I", crc32)) # 4字节 CRC32
 ser.write(struct.pack("<I", total_size)) # 固件总长度（可选）
 resp = ser.read(4)
 if resp != b"DONE":
 raise Exception("Bootloader校验失败，返回: %s" % resp)

# ---------------- 主流程 -----------------
with open("app.bin", "rb") as f:
 data = f.read()

# 计算 CRC32（和 Bootloader 保持一致）
crc32 = binascii.crc32(data) & 0xFFFFFFFF
total_size = len(data)
print(f"固件大小: {total_size} 字节, CRC32 = 0x{crc32:08X}")

# 分块发送（带进度条）
chunk_size = 256
with tqdm(total=total_size, unit="B", unit_scale=True, desc="升级中") as pbar:
 for i in range(0, total_size, chunk_size):
 chunk = data[i:i+chunk_size]
 send_data(chunk)
 pbar.update(len(chunk))

# 通知结束
send_end(crc32, total_size)
print("固件升级完成 ✅")

stm32端-增加校验

在CRC校验算法中，数据被视为一个巨大的二进制数，代表一个多项式的系数。生成多项式（CRC32_POLY）就是用来与这个数据多项式进行“模2除法”运算的除数，最终得到的余数就是CRC校验值。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


// 多项式 (Ethernet, ZIP, etc. 通用): 0x04C11DB7
#define CRC32_POLY 0xEDB88320UL
uint32_t crc32_calc(uint8_t *data, uint32_t length) {
 uint32_t crc = 0xFFFFFFFFUL;
 for (uint32_t i = 0; i < length; i++) {
 crc ^= data[i];
 for (uint8_t j = 0; j < 8; j++) {
 if (crc & 1) {
 crc = (crc >> 1) ^ CRC32_POLY;
 } else {
 crc >>= 1;
 }
 }
 }
 return ~crc;
}

bootloader逻辑改变

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43


#define APP_ADDR 0x08008000
#define CMD_START 0x01
#define CMD_DATA 0x02
#define CMD_END 0x03
void Bootloader_Update(void)
{
 uint8_t cmd;
 uint8_t buf[256];
 uint32_t addr = APP_ADDR;

 Flash_Erase_App();

 while(1)
 {
 HAL_UART_Receive(&huart1, &cmd, 1, HAL_MAX_DELAY);

 if(cmd == CMD_DATA) {
 uint16_t len;
 HAL_UART_Receive(&huart1, (uint8_t*)&len, 2, HAL_MAX_DELAY);
 HAL_UART_Receive(&huart1, buf, len, HAL_MAX_DELAY);

 Flash_Write(addr, buf, len);
 addr += len;

 HAL_UART_Transmit(&huart1, (uint8_t*)"OK", 2, HAL_MAX_DELAY);
 }
 else if(cmd == CMD_END) {
 uint32_t host_crc, host_size;
			HAL_UART_Receive(&huart1, (uint8_t*)&host_crc, 4, HAL_MAX_DELAY);
			HAL_UART_Receive(&huart1, (uint8_t*)&host_size, 4, HAL_MAX_DELAY);

			// 自己计算 CRC32
			uint32_t calc_crc = crc32_calc((uint8_t*)APP_ADDR, host_size);

			if (calc_crc == host_crc) {
				HAL_UART_Transmit(&huart1, (uint8_t*)"DONE", 4, HAL_MAX_DELAY);
			} else {
				HAL_UART_Transmit(&huart1, (uint8_t*)"FAIL", 4, HAL_MAX_DELAY);
			}
 break;
 }
 }
}