STM32 IAP upgrade design (HAL)
basic concepts
The internal FLASH of STM32 MCU has a specific starting address (0x80000000), and when STM32 starts, it will detect the status of the startup control pins BOOT0 and BOOT1, if it is designated to start from FLASH (the other two are SRAM startup and ISP corresponding Internal storage startup), address mapping is performed, 0x80000000 is mapped to address 0, and address 0 and word 1 address (0x80000004) are stored in the stack top address (indicating the available space of the memory SRAM, which is the 0 address of SRAM + The address after the effective space) and the reset interrupt response service program address. The CPU takes the top address of the stack as a parameter for subsequent SRAM operations. 0x80000004 is also the base address of the interrupt vector table used by the MCU to query the interrupt service routine address when an interrupt occurs. When resetting, take the reset interrupt service routine address from the first word address, jump to execute the SystemInit() function in the reset interrupt service routine, and then jump to execute the __main function after execution, and finally jump to the main() function.
For the implementation of IAP, a better way is to divide the code into two parts, boot and app. The boot part is the same as the original startup process, except that the main() function is the upgrade operation control process program. After the execution is completed, the interrupt is remapped. The vector table is the interrupt vector table of the app program. By obtaining the address of the reset interrupt service program in the interrupt vector table of the app program, it jumps and executes the main() function that finally realizes the running of the app program.
The app is stored in another area of FLASH. For the STM32CUBEIDE tool, to modify the starting address and range of the app program download, you need to modify STM32***TX_FLASH.ld. For example , change the sentence FLASH (rx): ORIGIN = 0x8000000, LENGTH = 128K to FLASH (rx): ORIGIN = 0x8008000 , LENGTH = 96K . The top address of the SRAM stack can also be modified (limit the RAM range used when the program is running), as shown in the following figure: The 
similar code in the boot code is as follows, check whether the first address of the app storage space is a valid stack top address (0x2FFE0000 Corresponding to the top of the stack with a check value of x0200020000 to avoid incorrect SRAM operation addresses) to verify whether the new app program has been written to the Flash storage space (optional, can be replaced by other methods). Note that the first address of the FLASH space occupied by the app cannot exceed the maximum address occupied by the boot FLASH.
In the app program, you also need to set an interrupt vector table offset address, which corresponds to the address offset of the app burned in Flash.
According
to
Change for STM32CUBEIDE, go to the Build Analyzer in Windows-Show View to see the storage space occupancy. Such as:
If you directly burn the boot and app parts through ST-LINK, pay attention to the separation of boot and app. When erasing the internal FLASH of the chip, realize partial erasing (only erase the burned sector) before writing Into. By default, STM32CUBEIDE erases all the sectors corresponding to the set FLASH address space before writing, and does not erase the physical FLASH space outside the set FLASH address space. Therefore, the non-overlapping FLASH address space is set for the boot and app program parts, and the programs can be burned in separately without affecting them. If you need more flexible control over the programming or view the FLASH situation, you can use STM32CubeProgrammer software (or STM32 ST-LINK Utility).
For the app program, a .bin file needs to be generated, so that the boot program receives the content of this file through an external interface and places it at the specific start address of the Flash. For STM32CUBEIDE, set in the post build settings
arm-none-eabi-objcopy "${ProjName}.elf" -O binary "${ProjName}.bin"
The boot program recommends using the chip's internal clock as the clock. The app uses an external clock or an internal clock for the clock based on the application requirements. In this way, the boot program process is not affected by the failure of the external clock, but if a more stable clock is required during the data transmission process, the boot program will also An external clock can be used for the clock.
Customized upgrade handshake protocol
- Because the write operation stability of the option byte is at risk, it is preferable that the last byte of the internal FLASH is used to upgrade the status control byte. It can be controlled by the user-side program to set its state (for example, 0x55 means that it will enter the long-waiting upgrade process after the next restart, and for other means it will only enter the short-waiting upgrade process). If there is an internal EEPROM, a byte can also be arranged from the internal EEPROM as the upgrade control byte. The bytes in the external EEPROM or FLASH space can also be used as upgrade control bytes. If you use the last byte of the STM32 internal FLASH as the upgrade control/identification byte, you must use the BYTE write and read function of the internal FLASH designed by yourself (with the original page data protection function, see: https://blog.csdn.net /hwytree/article/details/103907992).
- After STM32 is powered on or reset, check the highest bit of the status byte, if it is 0x55, it will enter the long wait state, and wait for the specific interface to receive a specific byte group (this byte group is only received once, and the subsequent ones are ignored. , Such as 0x55 0xaa 0x55 0xaa, the sender sends it once in 0.2s), send a specific byte group (such as 0x55 0xaa 0x55 0xaa) to the programming controller to indicate that data bytes can be sent, delay a specific time such as 0.5s to enter the data reception , The programming controller stops sending the upgrade instruction byte group, and sends data after a specific time delay such as 1s. STM32 receives the data through the timeout receiving method, such as 0x05 0x50 0x05 0x50+2 bytes of subsequent data bytes (high byte First) + 2 bytes of message number (numbering from 1 and high byte first), the received data part contains the same two pieces of data, which is convenient for STM32 to do valid reception verification. If the message number is continuous and If the data is verified correctly, put the valid data bytes into FLASH, and then send a specific byte group to the programming controller (such as 0x05 0x50 0x05 0x50); if the data check error or the message continuity check error is wrong, then Send a specific byte group to the programming controller (such as 0x05 0x0f 0x05 0x0f), and the programming controller will resend the wrong message. Once the reception of the whole process is completed, STM32 receives the byte group indicating the completion of the programming (such as 0xaa 0x55 0xaa 0x55), and then sets the status byte to 0 and initializes the originally initialized resources. Then enter the subsequent app jump process.
- After STM32 is powered on or reset, check the highest bit of the status byte, if it is 0, it enters a short wait state. If a specific upgrade instruction byte group is not received within a specific timeout period (such as 1S), the currently used byte group is released After the resource, jump to the app program. After the specific interface receives a specific byte group (for this byte group only once, the subsequent ones are ignored, such as 0x55 0xaa 0x55 0xa, the sender sends it once in 0.2s), and sends the specific byte group (such as 0x55 0xaa 0x55 0xaa) ) Instruct the programming controller to send data bytes, delay a specific time such as 0.5s to enter the data receiving state, the programming controller stops sending the upgrade instruction byte group, and send data after a specific time delay such as 1s, STM32 passes the timeout Receive data in receiving mode, such as 0x05 0x50 0x05 0x50+2 bytes of subsequent data bytes (high byte first) + 2 bytes of message number (numbering from 1, high byte first), received The data part contains the same two pieces of data, which is convenient for STM32 to perform effective reception verification. If the message number continuity and data verification are correct, put the valid data byte into FLASH, and then send a specific byte group to the programming control Party (such as 0x05 0x50 0x05 0x50); if the data check error or the message continuity check error is wrong, send a specific byte group to the programming controller (such as 0x05 0x0f 0x05 0x0f), and the programming controller will resend the wrong message . Once the reception of the whole process is completed, STM32 receives the byte group indicating the completion of the programming (such as 0xaa 0x55 0xaa 0x55), and initializes the originally initialized resources. Then enter the subsequent app jump process.
- If STM32 has multiple optional upgrade data transmission interfaces, after receiving the upgrade instruction specific byte group on a certain interface, you can close other interfaces, and only perform subsequent data transmission upgrades on this interface.
Embedded reference program
Based on STM32L031, it is easier to transplant code to STM32F1, F4 series.
STM32L031 complete IAP project (boot and app two parts) code (based on STM32CUBEIDE) download address:
https://download.csdn.net/download/hwytree/12839400
PC operating software
The Windows version, with the handshake protocol of the embedded version, can perform IAP upgrade operations.
PC software download address:
https://download.csdn.net/download/hwytree/12839411
-End-