目录

一 IAP功能介绍

二 IAP烧写流程说明

三 APP程序设计

四 IAP(BootLoader)程序设计

五 实际固件烧录

六 一些坑和注意点汇总

最近有个需求是，使用专用的手机APP，通过蓝牙模块的通信，实现嵌入式芯片上程序的在线升级，流程如下所示：

这个需求的核心要点在于MCU的串口IAP在线升级功能。

IAP即为In Application Programming,解释为在应用中编程，用户自己的程序在运行过程中对User Flash的部分区域进行烧写。即是一种对单片机flash擦写的一种编程方案。通常情况下，一片flash只有一个用户程序，而IAP编程则是将单片机的flash分成至少两大区域，一部分叫做bootloader区，一部分叫做app用户代码区，还可留出一部分区域为代码备份区。

Flash的地址在所使用的芯片说明书上有详细的介绍，以我这边使用的LPC18XX芯片来说，芯片中有两块大小为512K的Flash，分别为Flash A(0x1A000000-0x1A080000)与Flash B(0x1B000000-0x1B080000)，这两块Flash内部的扇区划分是一样的，都是8个8K的小扇区+7个64K的大扇区=512K，如下图所示：

根据上面的内存地址划分，MCU一上电，先从ROM A的起始地址0x1A000000开始执行。这样的话，设计将IAP程序放在ROM A的最开始段，比如0x1A000000-0x1A007FFF的32K空间（扇区号0-3），这里占据空间的大小根据实际的IAP程序大小决定。那么剩下来的ROM A中0x1A008000-0x1A07FFFF的480K空间（扇区号4-14）以及ROM B中0x1B000000-0x1B07FFFF的512K空间（扇区号0-14）就都分配给APP程序。

需要特别注意的是，要完成APP与IAP程序的切换判断，我们需要一个flag_update，当flag_update为0xFF的时候，视为正常上电状态，程序由IAP可以直接跳转到APP中执行；当flag_update为0x55的时候，视为远程烧写状态，程序由IAP开始之后，不跳转APP，而是执行自己的等待烧写流程。这边具体的流程和应用后面会具体介绍，这边捎带一提。为了满足切换判断的功能，就需要该标志位不随APP程序的烧写而发生变化，所以我这边选择将IAP存储区的最后一个字节，即地址0x1A007FFF作为flag_update的存储地址，这样，在IAP程序不变的情况下，随便怎么烧写APP，只要目标地址满足上述表格中的要求，该标志位就不会发生变化。当然，使用用其他满足条件的存储方式（诸如存入外部Flash、存入EEPROM等）都可以。

上面说完了IAP与APP的内存地址分配，接下来介绍一下IAP功能的流程：

【APP】：对于APP程序来说，需要实现的很简单，就是在串口收到某些外部指令的时候，将flag_update置为远程烧写状态（0x55），并重启。重启之后，MCU会重新从IAP程序开始执行，执行到flag_update判断，不跳转APP，进而执行IAP中等待升级文件的流程。

【IAP】：对于IAP程序来说，首先根据flag_update状态判断是否跳转APP，如果不跳转，则等待升级包。待升级包传输完毕，全部写到APP的地址中之后，再执行跳转到APP程序的起始地址执行（或者直接重启）。当然，跳转之前需要将flag_update重新置为正常上电状态（0xFF），这样以避免下一次重启之后，程序仍然跑在IAP中。

APP的程序主要包括地址配置和跳转IAP两方面功能：

【1】地址配置：

将其地址配置为功能介绍中规划的地址，同时在系统初始化程序中，将SCB->VTOR的地址配置为APP程序的起始地址：

【2】跳转IAP：

APP程序需要修改的核心程序体如下所示，串口收数据处理逻辑中，如果收到满足条件的通信码，则改写flag_update所在地址上的值：

其中，iap_init(BANK0)是用来初始化Flash A的，Iap_Write_Config_Value(0x55)是用来将flag_update置为0x55的：

Iap_Write_Config_Value中最为核心的接口就是copy_ram_to_flash，这个接口的作用就是将RAM中的数组iapConfigBuffer写到Flash中。这边需要注意的是，该接口复制字节的个数为512/1024/4096，所以我这边预设iapConfigBuffer数组长度为512，将这个数组最后一个元素置为0x55之后，复制到Flash的第3扇区尾部512字节长的区域，即地址段0x1A007E00-0x1A007FFF：

综上，便能实现APP程序中收到指令，修改flasg_update，再跳转IAP（重启）的功能。

相比于APP程序，IAP的设计会复杂一点，主要概括为以下几个点：地址配置、跳转APP、串口读写/回显、Ymodem移植等。

【1】地址配置：

将其地址配置为功能介绍中规划的地址，同时在系统初始化程序中，将SCB->VTOR的地址配置为APP程序的起始地址：

【2】跳转APP：

IAP程序中需要修改的核心程序体如下所示，上电IAP程序自检，如果位于0X1A007FFF的标志位值为0xFF，则进入APP程序地址运行，反之执行自身的烧写流程：

其中跳转接口runApp逻辑如下所示：

【3】串口读写/回显：

这边使用了MCU中的UART1串口，初始化如下，需要特别注意的是，IAP功能尽量不要启用中断，否则可能会带来不可预料的问题，这边将NVIC_EnableIRQ直接注释掉了：

不启用中断，直接判断串口寄存器的状态来进行接收发送，接收发送的逻辑分别封装在串口按键响应和串口回显中，分别如下：

【4】Ymodem移植：

核心程序体中可以看到，当输入"1"或者”2“时，会分别烧录第1或者第2块flash，传输协议选用Ymodem-1K。这一块的内容比较多，所以单列一篇帖子具体叙述，请参考：

【嵌入式】基于串口的IAP在线升级详解与实战2----移植Ymodem协议

上面的IAP与APP程序设计完成之后，就可以通过超级终端或者SecureCRT来进行IAP固件烧录了，我这边使用超极终端的Ymodem进行烧写（这边兼容Ymodem协议和蓝牙BLE的安卓APP还在进行中，待完成之后，就可以在手机上进行操作了）。

【1】首先打开超级终端，超级终端设置如下：

【2】接到串口上之后，重启MCU，会首先进入到IAP程序，此时flag_update为0x55，所以执行IAP烧写流程（如果首先flag_update是0xFF，首先进入的是APP程序，此时通过串口发一个指令即可修改flag_update并跳转IAP）。打印如下：

【3】这边我需要烧写的文件比较大，分摊在Flash1与Flash2中，所以需要分别烧写（一般需要烧写的文件比较小的话VTOR的赋值：

（3）外设中断的关闭：

现在芯片里有2套程序，大家都要使用外设中断寄存器来做中断相关的操作（配置，开启等），但是外设中断寄存器只有一套。如果Bootloader配置了一个定时器中断寄存器并开启，也写好了中断处理函数，然后没有disable它就跳转到APP去，而APP代码里没有使用定时器中断，也没有写中断处理函数，那么就会导致崩溃。因为配置好的定时器中断，到了定时时间要去执行中断处理函数，而中断向量表已经重定向了，现在的中断向量表里没有对应的中断处理函数。

看过前面的跳转代码的人可能会问：不是已经使用了__disable_irq()了吗，为什么还不行？因为这个语句是关的总中断，当跳到APP后需要重新开启总中断，那么到时候它下面的那些外设中断又重新开始运行了（外设中断寄存器的值没有被清除掉）。就跟家里的水阀和水龙头一个道理，水阀是总阀，水阀关了，即使水龙头开着也不会出水，但是如果水阀开着，那么水龙头出不出水就取决于水龙头的开关情况了。

所以我们在IAP程序中初始化串口的时候，需要在__disable_irq()语句之后，需要关掉中断。

另外，我们可以使用NVIC_DisableIRQ()来关闭外设中断。如果有多个中断开着，就多次调用这个函数，例如：

（4）不能重启的问题：我在使用中遇到了使用__set_FAULTMASK(1);NVIC_SystemReset();不能重启的情况，执行到这边之后就挂死了。后来参照着另外一个能够重启的工程，把程序的内核由CORE_M3改成了CORE_M4，就能够重启了。

虽然问题解决，但是原因还是没有搞清楚，后面询问NXP官方也没有得到清晰的答案。这边把问题贴出来，如果有大神看出来原因，希望不吝赐教。

（5）超级终端与SecureCRT上Ymodem-1K协议的使用有区别：

正常超级终端与SecureCRT两者发Ymodem-1K包，只可能是1024或者128两种包长，有效数据之外的部分用1A填充至标准包长。

但是，调试的最后遇到一个很奇怪的问题，就是超级终端与SecureCRT对于Ymodem-1K的使用有区别，主要区别在于尾包（文件总大小%1024）的处理上，当尾包大于128或者小于128，这两个软件的发包行为是有区别的：

数据段分成两个1K包：

1K+1K（192有效，剩余填充1A）

数据段分成一个1K包和一个128byte包：

1K+128（48有效，剩余填充为1A）

数据段分成一个1K包和两个128byte包：

1K+128+128（192-168=64有效，剩余填充为1A）

数据段分成一个1K包和一个128byte包：

1K+128（48有效，剩余填充为1A）

我的程序在尾包处理那边没有针对这个区别做特殊处理，所以目前只支持超级终端。

网上查询相关资料，应该是超级终端的这种形式符合参考链接中描述的Ymodem要求：（参考链接：http://www.51hei.com/bbs/dpj-32461-1.html）