惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

B
Blog
D
Docker
J
Java Code Geeks
腾讯CDC
Blog — PlanetScale
Blog — PlanetScale
G
Google Developers Blog
M
MIT News - Artificial intelligence
L
LangChain Blog
T
The Blog of Author Tim Ferriss
P
Proofpoint News Feed
MyScale Blog
MyScale Blog
博客园 - Franky
GbyAI
GbyAI
Hugging Face - Blog
Hugging Face - Blog
aimingoo的专栏
aimingoo的专栏
Last Week in AI
Last Week in AI
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
博客园 - 聂微东
N
Netflix TechBlog - Medium
B
Blog RSS Feed
Y
Y Combinator Blog
阮一峰的网络日志
阮一峰的网络日志
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Google DeepMind News
Google DeepMind News

博客园 - 痞子衡

痞子衡嵌入式:如果你嫌MCU板卡工厂验收测试麻烦,不妨试试FATestSuite 痞子衡嵌入式:大话双核i.MXRT1180之XIP应用里借助MU实现可靠Flash IAP的方法 痞子衡嵌入式:如果你在找针对i.MX RT系列的OTA参考设计,可以持续关注Tiny OTA 痞子衡嵌入式:Farewell, 我的写博故事2025 《痞子衡嵌入式半月刊》 第 120 期 痞子衡嵌入式:16MB以上NOR Flash地址模式切换会造成软复位后i.MXRT无法正常启动 痞子衡嵌入式:i.MXRT中FlexSPI外设速度上限的三个影响因子(数据手册里的纠结) 痞子衡嵌入式:在i.MXRTxxx下使能DMA动态链式传输误区及各外设驱动对DMA链式支持情况 痞子衡嵌入式:在i.MXRTxxx下使能DMA链式传输可达到SPI从设备接收速率上限50Mbps 痞子衡嵌入式:在i.MXRT下测试启动特性时可改写OTP Shadow寄存器而不烧OTP 痞子衡嵌入式:如果i.MXRT1xxx在Hab关闭时出现偶发性启动失败,请先检查JTAG电路 痞子衡嵌入式:恩智浦i.MX RT1xxx系列MCU启动那些事(11.B)- FlexSPI NOR连接方式大全(RT1180) 《痞子衡嵌入式半月刊》 第 119 期 痞子衡嵌入式:从i.MXRT600用户手册UM里一个关于FlexSPI LUT长度的勘误说起 痞子衡嵌入式:i.MXRT1170使用FlexSPI 2nd引脚组连接串行NOR Flash启动时FDCB需特殊设置 痞子衡嵌入式:MDK5.40下从DFP包路径添加用户下载算法FLM文件的方法 痞子衡嵌入式:i.MXRT10xx系列ROM的UART SDP设置不同波特率的方法与实践 痞子衡嵌入式:不处理i.MXRT1064片内Flash的RESET#引脚可能会导致无法启动或程序跑飞 痞子衡嵌入式:聊聊i.MXRT1024/1064片内4MB Flash的SFDP表易丢失导致的烧录异常 痞子衡嵌入式:在含多个i.MXRT的主从系统中共享一颗Flash启动的方法与实践(下篇)
痞子衡嵌入式:turbo-spiboot - 一种基于MCUBoot协议的二级SP...
痞子衡 · 2026-03-19 · via 博客园 - 痞子衡

  大家好,我是痞子衡,是正经搞技术的痞子。今天痞子衡给大家介绍的是一种基于MCUBoot协议的二级SPI加载APP提速方案

  在开始本文内容之前,有必要先介绍一下 MCUBoot 概念,这里并不是指 Zephyr RTOS 配套的那个 OTA 方案,而是指源于恩智浦 Kinetis 系列 BootROM 集成的那套与上位机交互的通信协议(又叫 blhost 协议)。

  目前 i.MX RT3digits 以及 RT1170/1180 均支持这套 MCUBoot 协议,该协议发展至今已有 10 多年,其实现相当稳定可靠,不过随着最近两年智能眼镜的火热,i.MXRT 三位数(RT600/700)作为协处理器在智能眼镜应用里大放光彩,MCUBoot 实现在这个应用场景下有一些性能瓶颈,主要表现在主处理器通过 MCUBoot 协议给协处理器加载 APP 的速度较慢,这就是本文要讨论的话题:

一、SPI加载APP方案应用场景

  当前智能眼镜普遍采用 MPU+MCU 双主控架构,在这样的架构下目前有两种非易失性存储器(NVM)搭配方式: 一、给两个主控分别搭配一块 NVM,存放各自的启动程序,互不依赖;二、只给 MPU 搭配一块 NVM,这块 NVM 同时存放 MPU,MCU的启动程序,MPU 启动后由其负责 MCU 的程序加载。

  两个存储器搭配方案各有优缺点,但在智能眼镜这个对 PCB 面积要求严苛的场景下,方案二目前是个大趋势,少用了一颗 NVM 节省了面积,不过也同时引入了额外启动时间(MPU 给 MCU 加载程序)。

  这里需要注意的是方案二并不是任何一个 MCU 都可以完成的,这个 MCU 一般情况下是 flashless 的,其需要有一个 BootROM,这个 BootROM 得支持从 Host 获取程序往内部 SRAM 加载并且还能够跳转执行,恩智浦 RT3digits 系列均支持这个特性。

  MCUBoot 协议通信接口方面,恩智浦 RT3digits 支持 UART, SPI, I2C, USB 四种,其中 SPI 是速度、主机实现复杂度、MPU 外设资源三方面考量的最均衡选择。

二、原SPI加载APP方案痛点

  我们直接从一个真实客户案例来看直接利用恩智浦 RT3digits BootROM 里的 MCUboot 协议实现完成 SPI 加载 APP 所需时间,这个客户设计的 RT685 程序约 1.3MB,其由高通 AR1 通过 SPI 加载所需总时间约为 3.8s,是不是觉得很长?

  让我们拆解这个时间组成,MCUBoot 协议规定最大一包交互数据为 512 个字节,那么 1.3MB 的程序需要分成约 2700 包进行传输,客户用示波器实际抓取发现一包 512 字节数据传输实际耗时约为 1.4ms。在这 1.4ms 里,包括纯数据包本身 SPI 传输时间(350s)、AR1 处理时间(750us)、RT685 处理时间(300us)。

  相信大家一眼就能发现时间大头消耗在 AR1 处理上,在与客户沟通过程中发现,AR1 端比较难优化(SPI 读写切换固定开销很大),那么即使我们努力减少 RT685 处理时间,整体加载时间优化效果也不会太理想。

三、二级SPI加载APP提速方案

  既然 AR1 端处理一包数据的 SPI 读写切换时间比较难优化,那么我们换个思路,能不能减少 AR1 需要处理的数据包数量呢?答案是可以的,这就是痞子衡要介绍的 SPI 二级加载方案。

  我们首先设计一个 32KB 以内的 RT685 loader 程序,先由 AR1 通过原来的方式加载这个 loader(预计额外耗时约 90ms),然后 loader 程序在 RT685 上运行起来之后,AR1 继续与 loader 进行交互完成最终 1.3MB 应用程序的加载。

  这里二级 loader 里与上位机交互协议方式实现是自由的,但为了 AR1 加载程序的一致性,我们可以在 RT685 loader 里沿用 MCUBoot 协议但对其进行一些优化,比如增大单包数据大小到 ~64KB,这样就可以将原先 1.3MB 共 2700 包的数据减少到 20 多包,相应的 AR1 处理次数也大幅下降,经此优化程序最终加载时间可从 3.8s 缩减到约 700ms。

  二级 loader 程序说起来很简单,其实具体设计起来还是有很多细节要考量的(痞子衡后续会详细介绍实现细节以及测试方法),因此痞子衡开源了这个项目(imxrt-turbo-spiboot),目前已经支持 RT500、RT685,后续还要增加支持 RT700 等系列。

  至此,一种基于MCUBoot协议的二级SPI加载APP提速方案痞子衡便介绍完毕了,掌声在哪里~~~

欢迎订阅

文章会同时发布到我的 博客园主页CSDN主页知乎主页微信公众号 平台上。

微信搜索"痞子衡嵌入式"或者扫描下面二维码,就可以在手机上第一时间看了哦。