STM32 IAP 升级设计（HAL完整例程及下载界面软件）
基本概念
STM32 MCU的内部FLASH有特定的起始地址（0x80000000），而STM32在启动时，会检测启动控制管脚BOOT0和BOOT1的状态，如果是指定从FLASH启动（另外两种是SRAM启动和ISP对应的内部存储启动），则会进行地址映射，将0x80000000映射为0地址，而0地址和字1地址（0x80000004），里面存放的分别是栈顶地址（指示内存SRAM可用空间，是SRAM的0地址+有效空间后的那个地址）和复位中断响应服务程序地址。CPU取了栈顶地址，作为后续SRAM操作时的参数。0x80000004也是发生中断时，MCU查询中断服务程序地址所用的中断向量表基址。复位时从第一个字地址取复位中断服务程序地址，在复位中断服务程序里跳转执行SystemInit()函数，执行完再跳转执行__main函数，最终跳转到main()函数。
对于IAP的实现，比较好的方式是分为两部分代码，boot和app部分，boot部分和原来的启动过程相同，只是main（）函数里是升级操作控制过程程序，执行完后，重新映射中断向量表为app程序的中断向量表，通过获取app程序中断向量表里的复位中断服务程序地址，跳转执行最终实现运行app程序的main()函数。
app存放于FLASH的另外一个区域，对于STM32CUBEIDE工具，修改app程序下载的起始地址和范围，需要修改 STM32***TX_FLASH.ld。如将FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 128K 一句，修改为 FLASH (rx) : ORIGIN = 0x8008000, LENGTH = 96K。SRAM的栈顶地址也可以修改（限制程序运行时使用的RAM范围），如下图所示位置：
boot代码里如下类似的代码，检查app存储空间首地址里存放的是否是有效栈顶地址, 以验证新的app程序是否已写到Flash存储空间（可选方式，可用其它方式替代）。注意app代码占用FLASH的地址区域，不能与boot代码的地址区域重叠。
#define FLASH_APP_ADDR 0x8004000
if ((*(__IO uint32_t*) FLASH_APP_ADDR) == 0x20010000) // RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 64K
app程序里，还需要设置一项中断矢量表偏移地址量，偏移量对应app在Flash烧录的地址偏移量。
根据已设置的app偏移地址
改为
不同类型的芯片，HAL库有差异，如果VECT_TAB_OFFSET不在上面的文件定义，则需要在工程目录，搜索出VECT_TAB_OFFSET定义的位置，并做相应的调整设置。如STM32F103ZET6的修改是在库文件system_stm32f1xx.c里修改：
原始文件为
修改为
对于STM32F0系列,又有所不同，没有可设置跳转的功能，中断矢量表放在内部RAM的初始空间，因此不设置跳转，而是将中断矢量表从FLASH拷贝到RAM，并正确指定程序所用的RAM空间段：
对于STM32CUBEIDE，在Windows-Show View里去找到Build Analyzer可以看到对存储空间的占用情况。如：
本设计的boot部分，一般情况下占用空间最大16KB，即地址偏移0x4000足够。同样的应用代码，不同芯片型号HAL库编译后的空间大小不一样，如果超过16KB，则可以稍加扩大到20KB即可。
如果直接将boot和app部分通过ST-LINK进行烧录，注意在boot和app分开情况，在对芯片内部FLASH进行擦除时，实现部分擦除（只擦除烧录的扇区）后再写入。 STM32CUBEIDE默认对所设置的FLASH地址空间对应的扇区做全部擦除后再写入，对于所设置的FLASH地址空间外的物理FLASH空间不做擦除。因此boot和app程序部分，设置好不重叠的FLASH地址空间，则程序可以分别烧录进去而不会产生影响。如果需要对烧录进行更灵活的控制或者查看FLASH情况,可以用STM32CubeProgrammer软件（或STM32 ST-LINK Utility）。
对于app程序，需要生成.bin文件，从而boot程序，通过外部接口接收此文件内容并放置于Flash特定开始地址。对于STM32CUBEIDE,在post build设置中设置
arm-none-eabi-objcopy "${ProjName}.elf" -O binary "${ProjName}.bin" boot程序建议采用芯片内部时钟供时钟，app基于应用要求采用外部时钟或内部时钟供时钟，如此，boot程序过程不受外部时钟故障的影响。
自定义的升级握手协议
- 因为选项字节的写操作稳定性存在风险，优选内部FLASH的最后一个字节用于升级状态控制字节。可以通过用户端程序控制，设置其状态（如为0x55表示下次重启后要进入长等待升级流程，为其它表示只进入短等待升级流程）。如存在内部EEPROM，也可从内部EEPROM安排一个字节用作升级控制字节。也可以用外部EEPROM或FLASH的空间里的字节用作升级控制字节。如用STM32内部FLASH的最后字节做升级控制/标识字节，要使用自行设计的内部FLASH的BYTE写读函数。
- STM32上电或复位后，检查状态字节的最高位，如果为0x55，则进入长等待状态，等待特定接口收到特定字节组后（对这个字节组只收一次，后面收到的忽略，如0x55 0xaa 0x55 0xaa，发送方0.2s发一次），发送特定字节组(如0x55 0xaa 0x55 0xaa)给烧录控制方指示可以发送数据字节，延时特定时间如0.5s进入数据接收状态，烧录控制方停止发送升级指示字节组，延时特定时间如1s后发送数据，STM32通过超时接收方式接收数据，如0x05 0x50 0x05 0x50+2个字节后续数据字节数(高字节在前)+ 2个字节报文编号(从1开始编号,高字节在前)，接收的数据部分含同样的两份数据，便于STM32做有效接收校验，如果报文编号连续性和数据都校验正确，将有效的数据字节放入FLASH，接着发送特定字节组给烧录控制方(如0x05 0x50 0x05 0x50) ；如果数据校验错误或报文连续性校验出错，则发送特定字节组给烧录控制方(如0x05 0x0f 0x05 0x0f)，烧录控制方重发出错的报文。一旦整个过程接收完成，STM32收到指示烧录完成的字节组（如0xaa 0x55 0xaa 0x55），则将状态字节置为0，并将原本初始化的资源去初始化。再进入到后续的app跳转流程。
- STM32上电或复位后，检查状态字节的最高位，如果不为0x55，则进入短等待状态，在特定的超时时间(如1S)未收到特定的升级指示字节组，则释放当前使用的资源后，跳转到app程序。特定接口收到特定字节组后（对这个字节组只收一次，后面收到的忽略，如0x55 0xaa 0x55 0xa， 发送方0.2s发一次），发送特定字节组(如0x55 0xaa 0x55 0xaa)给烧录控制方指示可以发送数据字节，延时特定时间如0.5s进入数据接收状态，烧录控制方停止发送升级指示字节组，延时特定时间如1s后发送数据，STM32通过超时接收方式接收数据，如0x05 0x50 0x05 0x50+2个字节后续数据字节数(高字节在前)+ 2个字节报文编号(从1开始编号,高字节在前)，接收的数据部分含同样的两份数据，便于STM32做有效接收校验，如果报文编号连续性和数据都校验正确，将有效的数据字节放入FLASH，接着发送特定字节组给烧录控制方(如0x05 0x50 0x05 0x50)；如果数据校验错误或报文连续性校验出错，则发送特定字节组给烧录控制方(如0x05 0x0f 0x05 0x0f)，烧录控制方重发出错的报文。一旦整个过程接收完成，STM32收到指示烧录完成的字节组（如0xaa 0x55 0xaa 0x55），将原本初始化的资源去初始化。再进入到后续的app跳转流程。
- 如果STM32有多个可选的升级数据传输接口，则在某一个接口上收到升级指示特定字节组后，将其它接口关闭即可，只在这个接口进行后面的数据传输升级。
嵌入式参考程序
基本跳转函数：
void JumpAPP(void) {
uint32_t JumpAddress;
pFunction Jump_To_Application;
//Check
if ((*(__IO uint32_t*) FLASH_APP_ADDR) == 0x20010000) // RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 64K
{
HAL_Delay(1);
// Jump to user application //
JumpAddress = *(__IO uint32_t*) (FLASH_APP_ADDR + 4);
Jump_To_Application = (pFunction) JumpAddress;
// Initialize user application's Stack Pointer //
__set_MSP(*(__IO uint32_t*) FLASH_APP_ADDR); //reset stack top; optional if stack to not changed
HAL_Delay(1);
Jump_To_Application(); //jump to app reset responding procedure
} else {
//No APP found!
}
}
STM32 IAP 升级设计（HAL完整例程及下载界面软件）
基本概念
STM32 MCU的内部FLASH有特定的起始地址（0x80000000），而STM32在启动时，会检测启动控制管脚BOOT0和BOOT1的状态，如果是指定从FLASH启动（另外两种是SRAM启动和ISP对应的内部存储启动），则会进行地址映射，将0x80000000映射为0地址，而0地址和字1地址（0x80000004），里面存放的分别是栈顶地址（指示内存SRAM可用空间，是SRAM的0地址+有效空间后的那个地址）和复位中断响应服务程序地址。CPU取了栈顶地址，作为后续SRAM操作时的参数。0x80000004也是发生中断时，MCU查询中断服务程序地址所用的中断向量表基址。复位时从第一个字地址取复位中断服务程序地址，在复位中断服务程序里跳转执行SystemInit()函数，执行完再跳转执行__main函数，最终跳转到main()函数。
对于IAP的实现，比较好的方式是分为两部分代码，boot和app部分，boot部分和原来的启动过程相同，只是main（）函数里是升级操作控制过程程序，执行完后，重新映射中断向量表为app程序的中断向量表，通过获取app程序中断向量表里的复位中断服务程序地址，跳转执行最终实现运行app程序的main()函数。
app存放于FLASH的另外一个区域，对于STM32CUBEIDE工具，修改app程序下载的起始地址和范围，需要修改 STM32***TX_FLASH.ld。如将FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 128K 一句，修改为 FLASH (rx) : ORIGIN = 0x8008000, LENGTH = 96K。SRAM的栈顶地址也可以修改（限制程序运行时使用的RAM范围），如下图所示位置：
boot代码里如下类似的代码，检查app存储空间首地址里存放的是否是有效栈顶地址, 以验证新的app程序是否已写到Flash存储空间（可选方式，可用其它方式替代）。注意app代码占用FLASH的地址区域，不能与boot代码的地址区域重叠。
#define FLASH_APP_ADDR 0x8004000
if ((*(__IO uint32_t*) FLASH_APP_ADDR) == 0x20010000) // RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 64K
app程序里，还需要设置一项中断矢量表偏移地址量，偏移量对应app在Flash烧录的地址偏移量。
根据已设置的app偏移地址
改为
不同类型的芯片，HAL库有差异，如果VECT_TAB_OFFSET不在上面的文件定义，则需要在工程目录，搜索出VECT_TAB_OFFSET定义的位置，并做相应的调整设置。如STM32F103ZET6的修改是在库文件system_stm32f1xx.c里修改：
原始文件为
修改为
对于STM32F0系列,又有所不同，没有可设置跳转的功能，中断矢量表放在内部RAM的初始空间，因此不设置跳转，而是将中断矢量表从FLASH拷贝到RAM，并正确指定程序所用的RAM空间段：
对于STM32CUBEIDE，在Windows-Show View里去找到Build Analyzer可以看到对存储空间的占用情况。如：
本设计的boot部分，一般情况下占用空间最大16KB，即地址偏移0x4000足够。同样的应用代码，不同芯片型号HAL库编译后的空间大小不一样，如果超过16KB，则可以稍加扩大到20KB即可。
如果直接将boot和app部分通过ST-LINK进行烧录，注意在boot和app分开情况，在对芯片内部FLASH进行擦除时，实现部分擦除（只擦除烧录的扇区）后再写入。 STM32CUBEIDE默认对所设置的FLASH地址空间对应的扇区做全部擦除后再写入，对于所设置的FLASH地址空间外的物理FLASH空间不做擦除。因此boot和app程序部分，设置好不重叠的FLASH地址空间，则程序可以分别烧录进去而不会产生影响。如果需要对烧录进行更灵活的控制或者查看FLASH情况,可以用STM32CubeProgrammer软件（或STM32 ST-LINK Utility）。
对于app程序，需要生成.bin文件，从而boot程序，通过外部接口接收此文件内容并放置于Flash特定开始地址。对于STM32CUBEIDE,在post build设置中设置
arm-none-eabi-objcopy "${ProjName}.elf" -O binary "${ProjName}.bin" boot程序建议采用芯片内部时钟供时钟，app基于应用要求采用外部时钟或内部时钟供时钟，如此，boot程序过程不受外部时钟故障的影响。
自定义的升级握手协议
- 因为选项字节的写操作稳定性存在风险，优选内部FLASH的最后一个字节用于升级状态控制字节。可以通过用户端程序控制，设置其状态（如为0x55表示下次重启后要进入长等待升级流程，为其它表示只进入短等待升级流程）。如存在内部EEPROM，也可从内部EEPROM安排一个字节用作升级控制字节。也可以用外部EEPROM或FLASH的空间里的字节用作升级控制字节。如用STM32内部FLASH的最后字节做升级控制/标识字节，要使用自行设计的内部FLASH的BYTE写读函数。
- STM32上电或复位后，检查状态字节的最高位，如果为0x55，则进入长等待状态，等待特定接口收到特定字节组后（对这个字节组只收一次，后面收到的忽略，如0x55 0xaa 0x55 0xaa，发送方0.2s发一次），发送特定字节组(如0x55 0xaa 0x55 0xaa)给烧录控制方指示可以发送数据字节，延时特定时间如0.5s进入数据接收状态，烧录控制方停止发送升级指示字节组，延时特定时间如1s后发送数据，STM32通过超时接收方式接收数据，如0x05 0x50 0x05 0x50+2个字节后续数据字节数(高字节在前)+ 2个字节报文编号(从1开始编号,高字节在前)，接收的数据部分含同样的两份数据，便于STM32做有效接收校验，如果报文编号连续性和数据都校验正确，将有效的数据字节放入FLASH，接着发送特定字节组给烧录控制方(如0x05 0x50 0x05 0x50) ；如果数据校验错误或报文连续性校验出错，则发送特定字节组给烧录控制方(如0x05 0x0f 0x05 0x0f)，烧录控制方重发出错的报文。一旦整个过程接收完成，STM32收到指示烧录完成的字节组（如0xaa 0x55 0xaa 0x55），则将状态字节置为0，并将原本初始化的资源去初始化。再进入到后续的app跳转流程。
- STM32上电或复位后，检查状态字节的最高位，如果不为0x55，则进入短等待状态，在特定的超时时间(如1S)未收到特定的升级指示字节组，则释放当前使用的资源后，跳转到app程序。特定接口收到特定字节组后（对这个字节组只收一次，后面收到的忽略，如0x55 0xaa 0x55 0xa， 发送方0.2s发一次），发送特定字节组(如0x55 0xaa 0x55 0xaa)给烧录控制方指示可以发送数据字节，延时特定时间如0.5s进入数据接收状态，烧录控制方停止发送升级指示字节组，延时特定时间如1s后发送数据，STM32通过超时接收方式接收数据，如0x05 0x50 0x05 0x50+2个字节后续数据字节数(高字节在前)+ 2个字节报文编号(从1开始编号,高字节在前)，接收的数据部分含同样的两份数据，便于STM32做有效接收校验，如果报文编号连续性和数据都校验正确，将有效的数据字节放入FLASH，接着发送特定字节组给烧录控制方(如0x05 0x50 0x05 0x50)；如果数据校验错误或报文连续性校验出错，则发送特定字节组给烧录控制方(如0x05 0x0f 0x05 0x0f)，烧录控制方重发出错的报文。一旦整个过程接收完成，STM32收到指示烧录完成的字节组（如0xaa 0x55 0xaa 0x55），将原本初始化的资源去初始化。再进入到后续的app跳转流程。
- 如果STM32有多个可选的升级数据传输接口，则在某一个接口上收到升级指示特定字节组后，将其它接口关闭即可，只在这个接口进行后面的数据传输升级。
嵌入式参考程序
基本跳转函数：
void JumpAPP(void) {
uint32_t JumpAddress;
pFunction Jump_To_Application;
//Check
if ((*(__IO uint32_t*) FLASH_APP_ADDR) == 0x20010000) // RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 64K
{
HAL_Delay(1);
// Jump to user application //
JumpAddress = *(__IO uint32_t*) (FLASH_APP_ADDR + 4);
Jump_To_Application = (pFunction) JumpAddress;
// Initialize user application's Stack Pointer //
__set_MSP(*(__IO uint32_t*) FLASH_APP_ADDR); //reset stack top; optional if stack to not changed
HAL_Delay(1);
Jump_To_Application(); //jump to app reset responding procedure
} else {
//No APP found!
}
}
举报
