设备固件升级需拆回原厂、依赖 J-LINK 等仿真器烧录?这一痛点可通过 IAP(In-Application Programming)升级方案彻底解决。本系列文章将以纳芯微NSSine™系列实时控制MCU/DSP芯片NS800RT5039为载体,通过《理论篇》与《实战篇》的结构化讲解,深度拆解“UART-Raw”协议下的IAP升级实现逻辑。内容覆盖全流程关键环节:从固件分区设计(Bootload区+APP区)的基础规划,到UART模块驱动开发、sct分散加载文件配置;从Jump跳转核心操作的原理剖析,到内部Flash擦写功能的代码落地,全程配套清晰流程图与可复用的代码清单,既为工程师提供扎实的理论指导,也助力快速完成设备现场固件升级,真正告别“拆机返厂”的低效模式。
IAP技术原理:告别返厂烧录的核心逻辑
经典的 IAP 方案采用 Bootloader(引导程序)+ App(应用程序)的双分区架构,Bootloader 负责烧录固件、通讯等功能;App 是实际的应用业务程序,也就是被升级的对象。双分区运行流程如下图所示:

图1 IAP方案流程
通常,带主控芯片的设备出厂时,应用代码会通过 J-LINK 等仿真器烧录至主控芯片。传统设备固件升级需将设备返厂,通过 J-LINK、CMSIS-DAP 等仿真器重新烧录代码,效率低、成本高。使用 IAP 技术可以在设备实际应用场景中通过通信接口即可实现固件更新,脱离烧录工具。
核心概念介绍
术语简述

中断向量表
NS800RT5039 内核基于 ARM 的 Cortex-M7,在 ARM 架构中,中断向量表(Interrupt Vector Table)是非常重要的一个组成部分,它定义了处理器发生中断时应该执行的中断服务函数的具体地址。
下方是中断向量表的示意图以及 NS800RT5039 中断向量表的部分定义:


图2 向量表结构
如上图所示,向量表第一个元素是“__initial_sp”,这个元素定义了程序系统初始的栈(STACK) 指针,也就是栈顶指针(为什么叫栈顶, 根据 CPU 指令架构,其所定义的栈的生长方向为向下生长,即从高地址到低地址生长,默认初始化时,指针的位置处于栈的顶部,因此叫栈顶指针)。而第二个元素“Reset”对应中断服务函数 Reset_Handler,这个元素定义的就是 Reset_Handler 函数的地址,该函数用作程序系统的入口函数。
向量表重定向
NS800RT5039 基于 Cortex-M7,支持向量表地址的重定向,也就是 SCB->VTOR 寄存器的功能,它可以指示向量表的地址,这个功能极大的方便了 IAP 的实现,从 BOOT 跳转到 APP 时,通过修改这个寄存器,就能实现向量表的切换。对于 APP 而言, BOOT 跳转之前 SCB->VTOR 指示的是 BOOT 的向量表,而非 APP 的向量表,所以必须在跳转到 APP 时手动重新加载 VTOR,以确保在 APP 运行时 CPU 能够正确响应到 APP 的中断向量表。
需要注意的是: 对于 Cortex-M7 系列芯片,向量表地址有对齐要求,简单而言,对齐数必须为 2 的整数幂,且不小于向量表总字节大小。举个例子, NS800RT7P65x 有 16 个内部中断, 227 个外部中断,总大小为 243 x 4 =972 Bytes,那么向量表对齐数必须不小于 972,同时需要满足为 2 的整数幂,所以210可作为它的对齐数,也就是 1024。
程序启动的标准流
硬件初始化 (系统时钟、外设、中断)
加载栈顶地址到SP寄存器,其位于中断向量表的第一个元素
读取 Reset 向量并跳转
向量表重定向
进行方案设计:实践前的关键决策
设计 Bootloader 与上位机的通讯协议, 为 Bootloader 开发数据传输功能
设计 Flash 烧录算法,为 Bootloader 开发烧录功能
确定如何从 Bootloader 区启动,运行 Bootloader 代码
确定如何从 App 区启动
确定 Bootloader 区与 App 区的固件地址,以及运行时地址,确保不相干涉
开发上位机
表1 常见IAP方案

在实际项目中,选择哪种 IAP 方案取决于成本、性能、可靠性要求、物理环境和安全性需求的综合权衡。对于大多数应用,UART 或 CAN IAP 是入门和通用的首选。
避坑要点:疑难杂症如何处理
App 跳转失败,程序跑飞
检查跳转流程是否正确
检查 Reset 函数(通常在启动文件中)是否正确调用 SystemInit 函数,以及堆栈初始化函数(在MDK中是 __main() )
检查 Reset 向量最后一位是否是 1 (1 代表 Thumb 模式,0 代表 ARM 模式)
检查在C语言代码中是否在设置栈顶地址后以及跳转前的同一个函数中使用了局部变量。因为设置栈顶地址会导致栈状态改变,局部变量会成为未定义的非法数据
跳转成功,但是后续调试出现 Hardfault
触发 Hardfault 后,查出出错地址,结合工程代码分析非法操作:
观察 Fault Reports 寄存器 (HFSR,CFSR、MMFAR、BFAR),寻找出错信息
查看 SP 寄存器,读取栈帧,获取出错前栈状态
BootLoader 应用层通信协议校验出错
调试芯片通讯外设,是否有错误标志,如FIFO溢出、校验失败等
使用逻分或示波器获取波形,排查上位机逻辑错误、排查硬件干扰、短路或接触不良
检查校验算法,是否与上位机一致,排查算法逻辑
Flash 烧写失败或无效
Flash 操作前是否正确关闭了 I/DCache
Flash 寄存器解锁操作是否正确
Flash 读写位宽和对齐是否符合要求
VDDIO 电源电压是否稳定 (Flash 擦写需要高压注入),PCB 电源滤波电容是否满足要求
编译 Flash 驱动时尽量不开启代码优化
其他注意事项
谨慎规划固件地址,避免 Bootloader 和 App 相互干涉,如 Bootloader 固件过大,超出规划区域导致被 App 固件误改等
Flash 在擦写时,不能同时对其进行读操作,若 CPU 对正在进行擦写的 Flash 有读请求,会导致 CPU 处于 halt 状态直到 Flash 响应请求
结论与建议
基于 NS800RT5039 的 IAP 实现,通过清晰的分区规划与稳定的通信、跳转与存储机制,使设备固件升级从“返厂烧录”转变为“现场完成”。该方案工程化程度高、代码可复用性强,覆盖了多数实际项目中容易踩坑的关键细节,适用于工业控制、消费电子等多类应用场景,可显著降低维护成本并提升系统可用性。
Previous:Microchip推出新型600V栅极驱动器
Online messageinquiry
| model | brand | Quote |
|---|---|---|
| CDZVT2R20B | ROHM Semiconductor | |
| TL431ACLPR | Texas Instruments | |
| BD71847AMWV-E2 | ROHM Semiconductor | |
| RB751G-40T2R | ROHM Semiconductor | |
| MC33074DR2G | onsemi |
| model | brand | To snap up |
|---|---|---|
| TPS63050YFFR | Texas Instruments | |
| STM32F429IGT6 | STMicroelectronics | |
| BP3621 | ROHM Semiconductor | |
| BU33JA2MNVX-CTL | ROHM Semiconductor | |
| IPZ40N04S5L4R8ATMA1 | Infineon Technologies | |
| ESR03EZPJ151 | ROHM Semiconductor |
Qr code of ameya360 official account
Identify TWO-DIMENSIONAL code, you can pay attention to
Please enter the verification code in the image below: