STM32F769 MJPEG视频播放与Bootloader升级实战

最近给一个用STM32F769做的中控面板做了一次大版本升级，核心诉求就一条：在现有UI里加视频播放。这个项目从需求评审到稳定量产，前后折腾了三个多月，踩了不少坑，包括怎么选视频方案、怎么把升级通道做安全、怎么在MCU的硬件资源限制下把帧率跑上去。今天把整个实现思路和关键代码细节整理出来，给有同样需求的朋友一个参考。适合正在做HMI/中控/家电面板类产品、准备给STM32项目加动效或视频功能、或者刚接触MCU图形开发想了解全流程的工程师看。

先说结论：STM32上跑视频，绝大多数场景不是真的去解码H.264，而是用MJPEG或帧序列方案，配硬件解码器和DMA2D做流水线。真正难的不是解码本身，而是帧数据从Flash到解码器再到屏幕的带宽管理，以及和UI事件、软件升级机制的协同。这篇文章会把选型思路、Bootloader分区设计、视频解码链路、调优手段、典型问题排查全部讲清楚。

1. 整体设计思路：STM32跑视频，先别急着写代码

1.1 先搞清楚你要的是"真视频"还是"伪视频"

这是整个项目第一个分岔路口。很多产品经理说"给界面加个视频"，实际想要的效果差异很大：

• 如果只是开机动画、操作引导、动态Logo，这类需求本质是帧序列动画。把画面预渲染成一组图片，按固定节奏播放，F103这种入门级MCU也能扛得住320x240分辨率。
• 如果是播放一段产品宣传片、演示视频，或者摄像头的实时画面回显，这才是真正意义上的视频解码，需要处理压缩数据流，对主频、内存、总线带宽都有硬要求。

我在项目启动前用一张表把这些需求列清楚，建议大家设计评审时也这么做。

这次项目的需求是播放一段45秒的产品演示动画，分辨率要到达320x240以上，最后选了MJPEG方案。理由很简单：MCU没有H.264硬解模块的话，纯软解H.264在F769上跑到15fps都很吃力，还会把CPU占满导致UI卡死；而MJPEG每一帧都是独立JPEG图，F769自带的硬件JPEG编解码器可以直接解，解码速度快，CPU占用低，还能随机跳帧，非常适合交互式播放。

1.2 从F103到H7的选型跨度，性能差距在哪

很多朋友一开始习惯性想用F103，觉得"我以前用F103做过LCD显示，加个视频应该也行"。这个认知得纠正一下，视频功能不是简单加个播放器库的事，它对硬件外设有明确需求：

• LTDC/LCD控制器：F103没有LTDC，只能用FSMC+RGB屏或者SPI方式刷屏，带宽严重不足。F429开始有LTDC和DMA2D，F769/H743在此基础上还有ART加速器和硬件JPEG解码器。
• DMA2D：做图像搬运、像素格式转换、混合叠加的关键外设。没有它的话，每一帧从解码缓冲复制到显示缓冲都要CPU参与，内存带宽直接被榨干。
• 外部存储接口：视频素材动辄几MB甚至十几MB，F103用SPI NOR Flash读帧最多每秒1~2MB，这连320x240x15fps的RGB565裸数据带宽（约2.3MB/s）都不够，更别提JPEG解码输入。F429/F769支持SDRAM和更高速的QSPI Flash，能显著缓解瓶颈。

我这次用的F769，主频216MHz，内部有硬件JPEG解码器，外扩了一片SDRAM和一片W25Q256 QSPI Flash。这个组合放320x240甚至640x360的MJPEG视频都够用，实测320x240@15fps解码时CPU占用大约25%，UI交互依然流畅。如果预算有限用F429，没有硬解JPEG，得用NanoJPEG软解，同样分辨率帧率会掉到8~10fps，但也不算完全不能用。

1.3 为什么还要单独设计Bootloader和分区

这可能是整个项目里最容易被低估的部分。我们做的是软件升级加视频功能，视频资源文件会跟着固件一起更新，但视频素材和程序代码的更新频率完全不同。如果每次UI改个按钮都要把几百KB的视频资源重新全量下发，用户升级时间会非常长，而且网络抖动一次就前功尽弃。

我采用的做法是把Bootloader、App、资源文件分区管理。App分区放程序固件，资源分区放视频、图片、字体，两者独立升级。Bootloader负责启动引导和接收升级包，校验通过后再把新数据写入对应分区。这样即使视频资源升级失败，App本身还是旧版本，系统能正常运行，不会变砖。

2. 软件升级通道设计：把Bootloader做得像运输队而不是门卫

2.1 MCU启动流程与分区地图规划

做Bootloader之前必须理解MCU的启动流程。STM32上电后从0x08000000读取栈顶指针和复位向量，跳到SystemInit，再进main。如果我们要让Bootloader跳转到App，就得在App里重映射中断向量表，用SCB->VTOR把向量表地址指到App起始位置。这里有一个特别容易踩的坑：App工程的起始地址和链接脚本必须和分区表一致，否则跳转后直接HardFault。

下面是我这次项目的Flash和外部Flash分区方案，可以直接参考：

App分区为什么留到448KB这么大？因为F769本身有1MB内部Flash，我一开始试图把代码压到256KB以内，结果功能一多编译体积就失控，后来干脆放宽到448KB。实际项目中这个尺寸还会根据功能模块动态调整，但记住一个原则：App分区宁大勿小，备份区必须有。

备份区的存在是为了实现"升级失败自动回滚"。升级流程是先把新固件写入备份区，完整写入并校验通过后再切换启动标志，下次重启由Bootloader决定运行哪个版本。如果中途断电，备份区和当前运行区都还能正常工作，这是A/B升级的基本思路，虽然费一点Flash空间，但极大降低变砖风险。

2.2 升级协议设计：用串口空闲中断收包最顺手

升级通道我选了串口，因为产品本身有串口调试口，而且不需要额外硬件。协议没有用Y-Modem，而是自定义了一套简单的分帧协议：帧头0xAA55 + 包序号 + 长度 + 命令字 + 数据 + CRC32。用串口空闲中断配合DMA接收，收满一帧就解析，解析完回ACK，下一帧再发，发完所有数据后再发结束包。

这里重点说下为什么用串口空闲中断。如果只做逐字节接收，任何一个字符延迟都会导致整包超时，调试时特别折磨人。开启HAL库的UART空闲中断后，一帧数据接收完毕会触发IDLE中断，我只需要在中断里记录当前DMA接收长度，就能精准定位帧边界，不需要自己拼包。这个思路不仅适合升级协议，任何串口帧协议都适用。

// 接收完一帧后进入该函数 void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size) { if (huart == &huart1) { rx_frame_len = Size; parse_frame_flag = 1; // 重新启动空闲中断+DMA接收，等待下一帧 HAL_UARTEx_ReceiveToIdle_DMA(&huart1, rx_buf, RX_BUF_SIZE); } }

固件校验层面，我用了CRC32加SHA256双保险。CRC32做快速初筛，SHA256在固件完全接收后做最终校验。有条件的话还建议加签名，业界常用做法是对固件包做AES-GCM加密或者Ed25519签名，防止被篡改。这里不展开密码学细节，但提醒一句：凡是能联网的升级机制，签名从第一天就要考虑，别等出问题再补。

2.3 视频资源怎么升级：独立资源分区的优势

视频素材是这次升级的核心，但它的升级路径和App不一样。我的方案是把视频编码成统一格式后放到外部QSPI Flash的资源分区，App代码里通过文件系统抽象层读取。这样视频资源升级时，只需要把旧的资源分区擦除、写入新素材，再更新一下资源索引表即可。App固件本身完全不用动。

实际操作中，资源升级和对App升级的链路是共用的，Bootloader收到"资源升级"命令后就进入资源接收模式，接收完普通校验、存到外部Flash。一旦中途异常退出，Bootloader会检查资源区的魔数（magic number）和版本号，发现无效就保持旧资源不切换，这是很实用的安全兜底。

3. 视频播放核心模块实现：解码、缓冲、渲染一条流水线

3.1 把视频预处理成MJPEG：分辨率、帧率、体积的平衡

视频源通常是MP4格式，工程上我们会先用ffmpeg把它转成MJPEG帧序列。转码时的参数选择直接影响播放效果和存储体积。下面是我经过多轮实测后比较稳的参数组合，适用于界面展示类视频：

ffmpeg -i input.mp4 \ -vf "scale=640:360" \ -r 15 \ -q:v 8 \ -pix_fmt yuvj420p \ output_%04d.jpg

几个参数的含义要理解清楚，才能根据需求调整：

• scale：分辨率。640x360是我给F769定的上限，再高解码压力大，且MJPEG文件体积会暴涨。如果是320x240，体积能缩小一半以上，播放更顺滑。
• -r 15：帧率。10fps属于"能看但有点卡"，15fps是流畅和开销的平衡点，20fps以上对MCU压力就大了。
• -q:v：JPEG质量，数值越小质量越高。实际测试中8左右画质可接受，文件比原始视频小很多；如果素材是卡通动画，可以适当提高压缩率。
• pix_fmt：用yuvj420p而不是yuv444，虽然画质略降，但解码更快，文件更小。

转完之后把这些JPEG帧按顺序打包进一个资源文件，再生成一个帧索引表（每帧的偏移量和长度），一并烧录到QSPI Flash。帧索引表的意义是支持随机访问播放，比如循环播放、跳转到某一段时间，不用每次从头部顺序扫描。

3.2 解码链路：DMA读Flash到JPEG解码器再到SDRAM

启动播放时，我的流水线分为三个阶段：

1. 读取：通过QSPI DMA把当前帧的JPEG数据从外部Flash搬进内存中的输入缓冲。
2. 解码：把输入缓冲交给硬件JPEG解码器（F769的JPEG模块），解码输出RGB565像素数据到SDRAM中的帧缓冲1。
3. 显示：把帧缓冲1中的像素通过DMA2D搬运到LTDC的当前帧缓冲，或者直接切换LTDC的显示地址。

这里有个很重要的技巧是双缓冲。解码器正在写帧缓冲1的同时，LTDC在显示帧缓冲0；下一帧解码完成后交换角色。这样显示端的刷新和解码端的写入不会互相干扰，画面上不会出现撕裂。如果能做三缓冲，还能进一步降低因解码抖动造成的掉帧，但内存消耗大，本项目的SDRAM够用，我最终用了三缓冲。

// 帧解码完成后的缓冲切换逻辑 void jpeg_decode_cplt_callback(void) { // 把刚解码完成的缓冲索引交给显示层 display_index = decode_index; // 解码器立刻开始解码下一帧到另一个缓冲 decode_index = 1 - decode_index; start_next_decode(decode_index); }

3.3 硬件JPEG解码器的使用要点

STM32F769的硬件JPEG解码器在HAL库里有现成驱动，但有一点必须注意：输出格式要在初始化时配置好。我使用RGB565输出，这样LTDC可以直接显示，不涉及像素格式转换。如果输出RGBA8888，界面叠加透明通道更方便，但内存占用翻倍，且DMA2D转换会多一步。

解码前要确保JPEG数据是完整的，不能只给一部分。硬件JPEG模块的内部状态机对数据边界很敏感，如果帧数据不完整，解码结果可能是花屏或者直接报错。我遇到过一次从QSPI Flash读帧时因为DMA配置错误导致只读了一半数据，画面就一直闪色块，这个问题的排查花了大半天。

解码性能方面，320x240@15fps时，F769硬件JPEG解码器几乎不占CPU，但DMA和总线带宽还是要关注。如果同时做视频解码和UI重绘，建议给DMA2D分配高优先级，LTDC刷新不能等。另外，打开了数据缓存（D-Cache）的情况下，解码缓冲和显示缓冲的Cache一致性要处理好，否则画面出现随机色点。

3.4 UI与视频叠加：用好DMA2D的混合能力

UI部分我用的LVGL。本来的设计是把视频解码后的帧直接当LVGL的图片对象显示，后来发现这个做法性能不行。LVGL内部有自己的刷新机制，如果视频帧以图片形式进入LVGL对象树，每次刷新都会走LVGL的绘图管线，CPU开销和内存复制都很大。

更高效的做法是：把视频播放窗口直接从LVGL的管理中摘出来。用LTDC的两个图层，图层0显示视频帧，图层1显示UI控件，两个图层在LTDC内部做硬件混合。UI界面上需要显示视频的区域，在视觉上留空，视频图层就从那个区域透出来。这样LVGL只刷新UI层，视频层由解码流水线独立驱动，两者互不阻塞。

如果你需要在视频上方叠加半透明控件或者字幕，可以利用LTDC的ALPHA混合功能。具体做法是给UI层配置一个全局透明度，或者在控件上单独使用DMA2D做alpha混合。我的经验是：能用硬件层混合解决的就别用软件混合，否则一帧图像叠加多个控件会把CPU拖垮。

3.5 帧率控制与播放进度管理

视频播放不能是死循环穷刷，也不能让UI中断打断播放。我用一个FreeRTOS定时器任务来管理播放时钟，每帧间隔用时间戳计算，比如15fps的间隔是66.7ms。定时器到时检查是否该显示下一帧，如果解码还没完成，就跳过这一帧（跳帧策略），避免累积时间的卡顿。

播放进度管理上，我额外维护了一个播放时间戳，音频（如果有）也用它来同步。这次项目不需要音频，如果后续要加配音或背景音乐，建议用PWM+DAC播放WAV，通过播放时间戳对齐，否则音画不同步会非常明显。

4. 调试实测与性能调优：从"能播"到"顺滑"的距离

4.1 实测数据与瓶颈定位

工程做到一半，我先用默认配置跑了一版，测量结果是这样的：320x240@15fps MJPEG视频，解码器工作正常，但UI刷新明显变慢，滑动列表的时候掉帧明显。用逻辑分析仪和STM32的性能计数器一抓，发现瓶颈不在CPU频率，而在SDRAM带宽。

问题出在：视频解码输出帧和UI显示帧都在SDRAM里，DMA2D搬运数据也要经过SDRAM，多个外设同时访问SDRAM时带宽被争抢。后来我把视频帧缓冲区的一部分移到内部RAM（F769有较大SRAM，但无法覆盖所有缓冲），再用DMA2D分块搬运，把一次大块搬运拆成多个小块，交错执行，画面帧率和UI流畅度都上来了。

4.2 常见问题与排查技巧

调试过程中积累了几个高频问题和对应的排查思路，直接整理成表，方便大家遇到类似情况快速定位。

特别说一下禁止JTAG释放引脚这个点，很多人会踩。F769的某些调试引脚默认复用为GPIO，如果产品需要这些引脚接外部设备，就得在代码里调用GPIO_PinLockConfig或者配置AFIO来禁用JTAG，只保留SWD。但是调试阶段千万别禁用，否则连不上调试器，只能用ST-Link Utility的Connect Under Reset模式恢复，非常麻烦。我一般是软件发布前才加上禁JTAG的配置。

4.3 嵌入式环境里的升级与调试工具链

开发过程中用到的工具链也简单分享一下。代码工程基于STM32CubeMX生成，IDE用的Keil MDK和VS Code交叉使用，CubeMX负责引脚配置和时钟树，具体逻辑代码在VS Code里写，最后用STM32CubeCLT的命令行工具做持续集成构建。如果你在Linux下做STM32开发，现在用STM32CubeCLT加OpenOCD加VS Code的组合已经很成熟，不再需要依赖Windows环境。

烧录和调试方面，日常调试用IAR/Keil的在线调试，批量生产用ST-Link批量烧录脚本，或者让产线利用Bootloader的串口升级通道烧录。STM32 ST-Link Utility这个老工具虽然官方停止更新了，但用来做整片擦除、读保护解除、手动下载hex仍然很顺手，生产返修时我经常用它。

5. 工程化落地与扩展方向

5.1 视频资源的包管理与版本控制

视频资源不能只管一次。产品后续迭代会不断换宣传片、换引导动画，因此资源包要有明确的版本号、素材格式约定和打包脚本。我这边做了一个小工具，把FFmpeg转出的JPEG帧、音频WAV、帧索引表打成一个res_pack_v3.bin，同时生成一个JSON描述文件，描述版本、分辨率、帧率、时长。Bootloader在升级资源时校验JSON里的CRC和版本号，只有版本递增时的资源才允许覆盖旧的。

如果你维护的产品线很多，建议把视频素材统一放在git仓库里做版本管理，由CI自动打包资源文件。这比在开发工程师本机手工转码可靠得多，至少不会出现"程序里调用第32帧，但资源包只有30帧"这种低级错误。

5.2 进阶玩法：远程升级、触摸手势、视频+音频

这次项目做完后，我还在往三个方向扩展：

第一是远程升级。MCU通过以太网或Wi-Fi模块联网，用HTTP拉取新固件和资源包，然后走已有的Bootloader升级通道。热词里提到了STM32的HTTP库，一般配合lwIP用，注意HTTP下载要做断点续传和超时重试，不能一断就从头来。

第二是触摸手势与视频联动。在视频播放层和UI层混合的前提下，可以做到滑动手势切换视频场景，或者在视频某帧停留时自动弹出控件。触控用的是电容触摸芯片，通过I2C把坐标送给MCU，在UI层做区域命中判断。这里涉及触摸校准和ADC采样，因为有些电容屏的坐标原始值是ADC值，需要做线性变换，可以参考常规的ADC多点校准方法，保证点击位置和UI控件对应准确。

第三是视频+音频同步。F769没有专用音频DAC，我计划用I2S外接一颗音频Codec播放WAV文件，播放进程和视频播放进程通过时间戳对齐。同步实现的关键是维护一个共同的媒体时钟，不能用两个任务各自计时，否则跑几秒钟之后音画就会差一截。

5.3 项目复盘：做带视频的MCU UI，哪些坑是可以提前绕开的

最后把经验集中复盘一下。

第一，视频方案要在硬件选型阶段就决定。如果产品规划里已经明确了要播放演示动画，直接选带LTDC、DMA2D和硬件JPEG解码器的型号（F429起步、F769/H743更好），别抱着F103不放，后面再迁移代价更高。

第二，Bootloader和App必须解耦。很多项目一开始不做Bootloader，后期要升级时再补，就会碰到Flash空间不够、启动向量冲突、升级协议与现有代码纠缠不清等问题。这次项目因为一开始就设计了独立Bootloader，后面加视频资源升级几乎是无痛迁移。

第三，帧率和清晰度是最典型的"产品语言"。给产品经理评审的时候，我直接提供从转码参数矩阵导出的几条demo：320x240@10fps、320x240@15fps、640x360@15fps、640x360@20fps，让业务方自己挑哪个效果能接受，再反推硬件成本。这比口头沟通高效很多，建议同行的朋友都用这个办法。

第四，升级失败率要当作核心质量指标。视频资源包通常比固件大得多，几MB的数据在串口或网络传输中出错的概率不低。协议要带分帧重传和断点续传，校验要够强，升级标志位要有看门狗兜底。宁可升级慢一点，也不能升级后变成砖。

写在后面

做MCU上的视频播放，最大的感受是"性能不是靠堆配置堆出来的，而是靠合理规划总线、缓冲和调度省出来的"。很多朋友拿到F769/H743觉得很强大，随手就把视频和UI都塞进LVGL，结果帧率上不去再去优化，绕了不少弯路。我个人现在做这类项目的标准顺序是：先定视频源和播放场景，再定数据存放介质和缓冲方案，最后才考虑UI框架怎么集成。把流水线设计清楚了，剩下的代码其实都是套路。

如果你也在做类似项目，遇到具体的解码花屏、升级回滚、帧率上不去这类问题，欢迎按文章里的排查表逐项对一遍，大概率能少走我走过的弯路。