来源 灵动MM32IAP（In Application Programming）即在应用程序编程，是一种自举程序。由于产品固化后不容易采用传统下载器更新固件使得许多产品中内置Bootloader程序用于远程更新固件，有的应用产品在产品固化后，只预留了USB、UART等通信接口，所以如果需要固件更新，只能考虑使用预留的通信接口进行更新固件操作，在一些上网设备或者无线设备上，也会使用到该功能，例如通过BLE、WIFI等无线通信进行固件更新，我们称为OTA（over the air technology)）空中下载技术，也是利用到了IAP升级的原理。 实现 IAP 功能时，即用户程序需要在运行中对自身的功能程序进行更新操作，需要在设计固件程序时编写两个项目代码，第一个项目程序不执行正常的功能操作，而只是通过某种通信方式（如 USB、UART、SPI等通信接口）接收程序或数据，执行对第二部分代码的更新，称之为 Bootloader 程序；第二个项目代码才是真正的功能代码，称之为 APP 程序，同时APP程序不仅可以在flash中运行也可以在SRAM中运行。这两部分项目代码都同时烧录在Flash的不同地址范围，一般从最低地址区开始存放Bootloader，紧跟其后的就是 APP 程序，MM32系列芯片flash容量有16k - 512k不同的容量，用户在设计IAP固件分区时需要规划好两个项目代码的地址分配。当芯片上电后，首先是第一个项目代码开始运行，它作如下操作：1、检查是否需要对第二部分代码进行更新（用户可以在此过程中加入一些校验功能，判断是否需要更新正确的代码）2、如果不需要更新则转到第四步（校验出现错误，继续执行原始的功能程序）3、执行更新操作4、跳转到第二部分代码执行第一部分代码必须通过其它手段，如SWD等方式烧入；第二部分代码可以使用第一部分代码 IAP 功能烧入，也可以和第一部分代码一起烧入，以后需要程序更新时再通过第一部分 IAP代码更新。 有的用户在IAP开发中用Bootloader 程序+ APP 程序1 + APP 程序2的方式，这个方式有一个好处就是如果APP更新不成功或者校验错误还可以跳转到另一个APP中运行功能程序，可以保证不会出现无固件的情况，防止设备变成板砖或死机等情况，不过该方法需要大容量的flash芯片或者外挂flash存储芯片，需要用户在开发中判断适合哪一种方式，原理与Bootloader 程序+ APP 程序相同，主要区别就是跳转的位置实现方法。1、IAP 负责通过flash的flag去判断启动app1 还是app2 2、 app1和app2 中通过UART或USB收数据去互相更新，比如，当前运行的是app1上就去更新app2，并且设置相应flag，最后软件重启跳到IAP判断flag启动哪一个的app2。 有的用户产生疑问，如果固件更新后，程序运行在APP功能程序中，假如需要第二次更新固件程序该如何处理呢？最简单直接的方法就是：设备做断电操作或者复位操作，在Bootloader 程序中会做判断执行Bootloader或APP。如果用户希望不做断电或复位操作，建议使用以下方式，如果用户在更新固件完成后，程序会跳转到APP程序中运行，如果需要第二次更新固件需要程序再次跳转到Bootloader程序，执行更新程序，如果用户在设备中有一个功能控制按键，可以利用该按键设备判断是执行Bootloader程序或者APP程序，在更新完成后，读取按键状态，判断是进入APP区域运行或者进入Bootloader区域，在主循环中然后再做判断是执行执行Bootloader程序或者APP程序，这样就可以实现二次更新下载程序，在这里介绍一种客户常用的方式，如何MM32用户有更好的操作方案，欢迎大家通过MM32论坛或者MM32 QQ群等交流途径提出更好的方案，方便大家一起讨论优缺点。 APP程序二次更新操作配置
在主程序的循环函数可以看到，进while(1)后，我会去判断key3的电平状态，如果key3被按下，初始化用户程序的堆栈指针，生成跳转函数，实际失去app复位地址去执行复位操作，程序将跳转到Bootloader区域执行Bootloader，等到固件更新。 在前期的《MM32 IAP中断向量表重定义》的文章中有给大家介绍中断向量表的重定义的配置方法，在Cortex-M3内核的MCU上可以通过设置SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET；该寄存器的值来实现中断向量表的重定义。但在MM32L0xx系列以Cortex-M0为内核是没有SCB->Vector寄存器，需要重新将48个中断向量表填充为APP的中断向量表并开启RCCAPB2ENR中SYSCFGEN位打开SYSCFG配置时钟配置SYSCFG->CFGR1中MEM_MODE，配置为0x3，嵌入式SRAM映射到首地址（系统复位后会自动根据BOOT引脚电平配置这2位，设置这2位作用是系统从哪里获取向量表，复位后自动从ROM映射的起始地址取向量表，这里向量表已经被更新了，所以设置为0x3使得SRAM中的向量表地址被映射到起始地址）。1、将中断向量表放入到RAM的起始地址（只需要在应用程序中保留RAM起始地址的0x100大小不使用即可）。2、在bootload中将应用程序的中断向量表从Flash中拷贝到RAM中。3、设置MM32L073中断向量表位于RAM中。 APP程序配置流程：
MM32的flash的起始地址是0x08000000，程序文件就是从这个地址开始写入。本次实验使用的MM32L073PF有128k的flash，所以从0x08000000至0x08020000的128k空间是程序存储的空间。设置起始地址（Start）为0X08010000，即偏移量为 0X10000（64K 字节），APP 用的 FLASH 空间（Size）只有0X20000-0X10000=0X10000（64K 字节）大小了。设置好 Start 和Size，就完成 APP 程序的起始地址设置。这里的 64K 字节，需要用户根据Bootloader 程序大小进行选择，在应用开发时设计者根据应用的需求和芯片的flash容量合理分配空间，注意不要出现溢出等情况，有很多客户在使用IAP功能时，会进入hardfault，最后查找发现是flash出现溢出，这个在开发时需要注意。
Keil默认生成的是hex文件（ASCII码的文本文件，HEX文件内部的信息已经包括了地址），但是IAP升级的是.bin文件（包括了纯粹的二进制数据，在烧写时用户需要指定地址信息）。用户可以在APP工程中先生成hex文件，然后使用灵动微电子为方便客户转换文件的hex2bin工具，使用keil有自带的格式转换工具 fromelf.exe，来实现.axf 文件到.bin 文件的转换。有兴趣的用户可以自行百度深入了解操作方法。 灵动微电子hex2bin工具
本次实验主要向大家介绍了IAP的基本理论和APP程序编写方法，下一期将向大家介绍在MM32L073PF上实现Bootloader 程序。
来源 灵动MM32IAP（In Application Programming）即在应用程序编程，是一种自举程序。由于产品固化后不容易采用传统下载器更新固件使得许多产品中内置Bootloader程序用于远程更新固件，有的应用产品在产品固化后，只预留了USB、UART等通信接口，所以如果需要固件更新，只能考虑使用预留的通信接口进行更新固件操作，在一些上网设备或者无线设备上，也会使用到该功能，例如通过BLE、WIFI等无线通信进行固件更新，我们称为OTA（over the air technology)）空中下载技术，也是利用到了IAP升级的原理。 实现 IAP 功能时，即用户程序需要在运行中对自身的功能程序进行更新操作，需要在设计固件程序时编写两个项目代码，第一个项目程序不执行正常的功能操作，而只是通过某种通信方式（如 USB、UART、SPI等通信接口）接收程序或数据，执行对第二部分代码的更新，称之为 Bootloader 程序；第二个项目代码才是真正的功能代码，称之为 APP 程序，同时APP程序不仅可以在flash中运行也可以在SRAM中运行。这两部分项目代码都同时烧录在Flash的不同地址范围，一般从最低地址区开始存放Bootloader，紧跟其后的就是 APP 程序，MM32系列芯片flash容量有16k - 512k不同的容量，用户在设计IAP固件分区时需要规划好两个项目代码的地址分配。当芯片上电后，首先是第一个项目代码开始运行，它作如下操作：1、检查是否需要对第二部分代码进行更新（用户可以在此过程中加入一些校验功能，判断是否需要更新正确的代码）2、如果不需要更新则转到第四步（校验出现错误，继续执行原始的功能程序）3、执行更新操作4、跳转到第二部分代码执行第一部分代码必须通过其它手段，如SWD等方式烧入；第二部分代码可以使用第一部分代码 IAP 功能烧入，也可以和第一部分代码一起烧入，以后需要程序更新时再通过第一部分 IAP代码更新。 有的用户在IAP开发中用Bootloader 程序+ APP 程序1 + APP 程序2的方式，这个方式有一个好处就是如果APP更新不成功或者校验错误还可以跳转到另一个APP中运行功能程序，可以保证不会出现无固件的情况，防止设备变成板砖或死机等情况，不过该方法需要大容量的flash芯片或者外挂flash存储芯片，需要用户在开发中判断适合哪一种方式，原理与Bootloader 程序+ APP 程序相同，主要区别就是跳转的位置实现方法。1、IAP 负责通过flash的flag去判断启动app1 还是app2 2、 app1和app2 中通过UART或USB收数据去互相更新，比如，当前运行的是app1上就去更新app2，并且设置相应flag，最后软件重启跳到IAP判断flag启动哪一个的app2。 有的用户产生疑问，如果固件更新后，程序运行在APP功能程序中，假如需要第二次更新固件程序该如何处理呢？最简单直接的方法就是：设备做断电操作或者复位操作，在Bootloader 程序中会做判断执行Bootloader或APP。如果用户希望不做断电或复位操作，建议使用以下方式，如果用户在更新固件完成后，程序会跳转到APP程序中运行，如果需要第二次更新固件需要程序再次跳转到Bootloader程序，执行更新程序，如果用户在设备中有一个功能控制按键，可以利用该按键设备判断是执行Bootloader程序或者APP程序，在更新完成后，读取按键状态，判断是进入APP区域运行或者进入Bootloader区域，在主循环中然后再做判断是执行执行Bootloader程序或者APP程序，这样就可以实现二次更新下载程序，在这里介绍一种客户常用的方式，如何MM32用户有更好的操作方案，欢迎大家通过MM32论坛或者MM32 QQ群等交流途径提出更好的方案，方便大家一起讨论优缺点。 APP程序二次更新操作配置
在主程序的循环函数可以看到，进while(1)后，我会去判断key3的电平状态，如果key3被按下，初始化用户程序的堆栈指针，生成跳转函数，实际失去app复位地址去执行复位操作，程序将跳转到Bootloader区域执行Bootloader，等到固件更新。 在前期的《MM32 IAP中断向量表重定义》的文章中有给大家介绍中断向量表的重定义的配置方法，在Cortex-M3内核的MCU上可以通过设置SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET；该寄存器的值来实现中断向量表的重定义。但在MM32L0xx系列以Cortex-M0为内核是没有SCB->Vector寄存器，需要重新将48个中断向量表填充为APP的中断向量表并开启RCCAPB2ENR中SYSCFGEN位打开SYSCFG配置时钟配置SYSCFG->CFGR1中MEM_MODE，配置为0x3，嵌入式SRAM映射到首地址（系统复位后会自动根据BOOT引脚电平配置这2位，设置这2位作用是系统从哪里获取向量表，复位后自动从ROM映射的起始地址取向量表，这里向量表已经被更新了，所以设置为0x3使得SRAM中的向量表地址被映射到起始地址）。1、将中断向量表放入到RAM的起始地址（只需要在应用程序中保留RAM起始地址的0x100大小不使用即可）。2、在bootload中将应用程序的中断向量表从Flash中拷贝到RAM中。3、设置MM32L073中断向量表位于RAM中。 APP程序配置流程：
MM32的flash的起始地址是0x08000000，程序文件就是从这个地址开始写入。本次实验使用的MM32L073PF有128k的flash，所以从0x08000000至0x08020000的128k空间是程序存储的空间。设置起始地址（Start）为0X08010000，即偏移量为 0X10000（64K 字节），APP 用的 FLASH 空间（Size）只有0X20000-0X10000=0X10000（64K 字节）大小了。设置好 Start 和Size，就完成 APP 程序的起始地址设置。这里的 64K 字节，需要用户根据Bootloader 程序大小进行选择，在应用开发时设计者根据应用的需求和芯片的flash容量合理分配空间，注意不要出现溢出等情况，有很多客户在使用IAP功能时，会进入hardfault，最后查找发现是flash出现溢出，这个在开发时需要注意。
Keil默认生成的是hex文件（ASCII码的文本文件，HEX文件内部的信息已经包括了地址），但是IAP升级的是.bin文件（包括了纯粹的二进制数据，在烧写时用户需要指定地址信息）。用户可以在APP工程中先生成hex文件，然后使用灵动微电子为方便客户转换文件的hex2bin工具，使用keil有自带的格式转换工具 fromelf.exe，来实现.axf 文件到.bin 文件的转换。有兴趣的用户可以自行百度深入了解操作方法。 灵动微电子hex2bin工具
本次实验主要向大家介绍了IAP的基本理论和APP程序编写方法，下一期将向大家介绍在MM32L073PF上实现Bootloader 程序。
在主程序的循环函数可以看到，进while(1)后，我会去判断key3的电平状态，如果key3被按下，初始化用户程序的堆栈指针，生成跳转函数，实际失去app复位地址去执行复位操作，程序将跳转到Bootloader区域执行Bootloader，等到固件更新。 在前期的《MM32 IAP中断向量表重定义》的文章中有给大家介绍中断向量表的重定义的配置方法，在Cortex-M3内核的MCU上可以通过设置SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET；该寄存器的值来实现中断向量表的重定义。但在MM32L0xx系列以Cortex-M0为内核是没有SCB->Vector寄存器，需要重新将48个中断向量表填充为APP的中断向量表并开启RCCAPB2ENR中SYSCFGEN位打开SYSCFG配置时钟配置SYSCFG->CFGR1中MEM_MODE，配置为0x3，嵌入式SRAM映射到首地址（系统复位后会自动根据BOOT引脚电平配置这2位，设置这2位作用是系统从哪里获取向量表，复位后自动从ROM映射的起始地址取向量表，这里向量表已经被更新了，所以设置为0x3使得SRAM中的向量表地址被映射到起始地址）。1、将中断向量表放入到RAM的起始地址（只需要在应用程序中保留RAM起始地址的0x100大小不使用即可）。2、在bootload中将应用程序的中断向量表从Flash中拷贝到RAM中。3、设置MM32L073中断向量表位于RAM中。 APP程序配置流程：
MM32的flash的起始地址是0x08000000，程序文件就是从这个地址开始写入。本次实验使用的MM32L073PF有128k的flash，所以从0x08000000至0x08020000的128k空间是程序存储的空间。设置起始地址（Start）为0X08010000，即偏移量为 0X10000（64K 字节），APP 用的 FLASH 空间（Size）只有0X20000-0X10000=0X10000（64K 字节）大小了。设置好 Start 和Size，就完成 APP 程序的起始地址设置。这里的 64K 字节，需要用户根据Bootloader 程序大小进行选择，在应用开发时设计者根据应用的需求和芯片的flash容量合理分配空间，注意不要出现溢出等情况，有很多客户在使用IAP功能时，会进入hardfault，最后查找发现是flash出现溢出，这个在开发时需要注意。 
Keil默认生成的是hex文件（ASCII码的文本文件，HEX文件内部的信息已经包括了地址），但是IAP升级的是.bin文件（包括了纯粹的二进制数据，在烧写时用户需要指定地址信息）。用户可以在APP工程中先生成hex文件，然后使用灵动微电子为方便客户转换文件的hex2bin工具，使用keil有自带的格式转换工具 fromelf.exe，来实现.axf 文件到.bin 文件的转换。有兴趣的用户可以自行百度深入了解操作方法。 灵动微电子hex2bin工具
本次实验主要向大家介绍了IAP的基本理论和APP程序编写方法，下一期将向大家介绍在MM32L073PF上实现Bootloader 程序。
