Based on the STM32AIP design document (Bootloader+3app)

Bootloader+3app

 

 

 

 

 

1 Introduction: 2

2 Bootloader Implementation principle: 3

3 app Implementation and configuration: 6

3.1 APP1 program Start address setting Method: 6

3.2 Interrupt vector table offset setting: 7

3.3 *bin file Generation: 7

3.4-Step Summary: 8

4 Key points: 9

Attachment:.. 10

 

 

 

1 Introduction

IAP (in application programming) is the application programming, IAP is the user's own program in the process of running a portion of user flash to write, The purpose is to update and upgrade the firmware in the product after the release of the product, conveniently through the reserved communication port. When the IAP function is usually implemented, that is, the user program is running in its own update operation, need to write two project code in the design of the firmware program, the first project program does not perform normal function operation, but only through some means of communication (such as USB, USART) to receive the program or data, the second part of the code to perform the update The second project code is the real function code. Both parts of the project code are simultaneously burned in user flash, when the chip power, the first is the first project code to start running, it does the following:

1) Check if you need to update the second part of the code

2) Go to 4 if no update is required)

3) Perform the update operation

4) Jump to the second part of the Code execution

The first part of the code must be burned by other means, such as JTAG or ISP, the second part of the code can be burned with the first part of the Code IAP function, or can be burned with the first part of the code, and later need to update the program through the first part of the IAP code updates.

We call the first project code the Bootloader program, the second project code is called the app, they are stored in the STM32 flash different address range, generally starting from the lowest address area to store bootloader, followed by the app (note, If the flash capacity is enough, you can design a lot of apps, this chapter we discuss the situation of 3 app programs. So we're going to implement 4 programs: Bootloader and 3 apps.

2 bootloader Implementation principle

Let's take a look at STM32 normal program run flow, as shown in Figure 2.1:

Figure 2.1 STM32 normal operation flowchart

STM32 's internal flash (Flash) address starts at 0x08000000, and in general, the program file is written from this address. In addition, STM32 is based on the CORTEX-M3 core microcontroller, the internal through a "interrupt vector table" to respond to interrupts, after the program starts, will first remove the reset interrupt vector from the "Interrupt vector table" to perform the reset interrupt program to complete the start, and this "interrupt vector table" The starting address is 0x08000004, when the interrupt arrives, the internal hardware mechanism of STM32 automatically locates the PC pointer at the interrupt vector table, and executes the interrupt service program based on the interrupt source to remove the corresponding interrupt vector.

In Figure 2.1, STM32 after the reset, first remove the address of the reset interrupt vector from the 0x08000004 address, and jump to the reset interrupt service program, as shown in Figure designator ①; After the reset interrupt service program executes, it jumps to our main function, as shown in the figure designator ②, and our main function is generally a dead loop, During the execution of the main function, if an interrupt request (a heavy interrupt occurs) is received, STM32 forces the PC pointer back to the interrupt vector table, as shown in Figure ③, and then enters the appropriate interrupt service according to the source of the interrupt, as shown in Figure designator ④; After executing the interrupt service program, The program returns the main function execution again, as shown in Figure designator ⑤.

When you join the IAP program, the program runs as shown in Figure 2.2:

Figure 2.2 Program run flowchart after adding IAP

In the process shown in Figure 2.2, the STM32 reset, or remove the address of the reset interrupt vector from the 0x08000004 address, and jump to the reset interrupt service program, after running the Reset interrupt service program to jump to the main function of the IAP, as shown in Figure designator ①, this part is the same as figure 2.1; After the IAP is executed (the new The app code is written to the STM32 Flash, gray-bottomed section. The new program's reset interrupt vector start address is 0x08000004+n+m), jump to the new write program's reset vector table, remove the new program's reset interrupt vector address, and jump to execute the new program's Reset interrupt service program, and then jump to the new program's main function, as shown in the figure designator ② and ③, The same main function is a dead loop, and note that at this time STM32 Flash, in different locations, there are two interrupt vector tables.

During the execution of the main function, if the CPU gets an interrupt request, the PC pointer still forces a jump to the address 0x08000004 interrupt vector table instead of the new program's Interrupt vector table, as shown in Figure ④, and the program again based on the Interrupt vector table offset we set, Jump to the corresponding interrupt source in the new interrupt service program, as shown in Figure designator ⑤; After executing the interrupt service program, the program returns to the main function to continue running, as shown in Figure designator ⑥.

Through the analysis of the above two processes, we know that the IAP program must meet two requirements:

1) The new program must start at an offset of x after the IAP program;

2) The new program must move the interrupt vector table accordingly, moving the offset to x;

3 app Implementation and configuration

This chapter designs 3 apps, because it is a different flash sector, so it's one of the examples. 3.1 APP1 program start address setting method

To open a previous instance project, click the Options for Targetàtarget tab, as shown in Figure 3.1:

Figure 3.1 FLASH APP1 target tab settings

By default, the starting address (start) of the IROM1 in the figure is generally 0x08000000, with a size of 0x80000, which is the 512K space starting from 0x08000000 for our program storage. In the figure, we set the start address (start) to 0x08010000, which is the offset of 0X10000 (64K bytes), so the flash space (size) left for the app is only 0x80000-0x10000=0x70000 (448K bytes) in size. Set start and Szie to complete the start address setting of the APP1 program.

APP2 is the 0x08020000+0x60000;

APP3 is the 0x08030000+0x50000;

In fact, each app is allocated 4k of space.

3.2 Offset setting for interrupt vector table

As we have explained before, when the system starts, it calls the Systeminit function to initialize the clock system, and Systeminit also completes the interrupt vector table setting, so we can open the Systeminit function to see that there are several lines of code at the end of the function body:

#ifdef Vect_tab_sram

Scb->vtor = Sram_base | Vect_tab_offset;

/* Vector Table relocation in Internal SRAM. */

#else

Cb->vtor = Flash_base | Vect_tab_offset;

/* Vector Table relocation in Internal FLASH. */

#endif

From the code, it is understandable that the Vtor register holds the starting address of the interrupt vector table. The default condition Vect_tab_sram is undefined, so do scb->vtor = Flash_base | Vect_tab_offset; For the Flash app, we set the flash_base+ offset to 0x10000, so we can add the following code at the beginning of the main function of the Flash app to reset the start address of the Interrupt vector table:

Scb->vtor = Flash_base | 0x10000

If it is APP2 can be set to Scb->vtor = Flash_base | 0x20000

If it is APP3 can be set to Scb->vtor = Flash_base | 0x30000;

In this way, we have completed setting the Interrupt vector table offset. 3.3 *bin file generation

However, the MDK default generated file is a. hex file, which is not convenient for us to use as an IAP update, and we want the generated file to be a. bin file, which makes it easy to upgrade the IAP. Here we implement the conversion of the. axf file to the. bin file by MDK The format conversion tool Fromelf.exe. The tool is in the MDK installation directory \arm\bin40 folder.

In this chapter, by clicking on the options for Targetuser tab in MDK, in the run User Programs after Build/rebuild bar, check run#1 and DOS16, and write: D:\Keil3.80a\ARM\ Bin40\fromelf.exe--bin-o. \obj\test.bin. \OBJ\TEST.AXF, as shown in Figure 3.2:

Figure 3.2 *bin file generation settings

with this step set, we can call Fromelf.exe after the MDK is compiled successfully (note that my MDK is installed in D:\ keil3.80a folder, if you are installed in another directory, please modify the path of Fromelf.exe according to your own directory, according to the current project TEST.AXF (if it is another name, please remember to modify, this file is stored in the obj directory, the format is XXX.AXF), generate a test.b in file. and stored in the same directory as the AXF file, that is, the project obj folder inside. After getting the. bin file, we only need to transfer the bin file to the microcontroller to perform the IAP upgrade. 3.4 Steps Summary

1) Set the start address and storage size of the app program

2) set interrupt vector table offset

3) set the compile and run Fromelf.exeto generate the . bin file .

4 key points

1) The IAP program must meet two requirements:

1. The new program must start at an offset of x after the IAP program;

2. You must move the interrupt vector table of the new program accordingly, and move the offset to x;

2) STM32 is in accordance with the half-word read and write data to flash inside, so the serial port to send and receive data, must set up a send and receive completion flag, only the data will be accepted after the update. Also, a delay must be set between receiving and transmitting data.

3) must be updated after the execution, the corresponding settings in the program a flag bit. Flag.

Important: Be sure to assign an offset address to each app.

Reserved 0X08000000~0X0800FFFF space for IAP use

#define FLASH_APP1_ADDR 0x08010000//First application start address (stored in FLASH)

#define FLASH_APP2_ADDR 0x08020000//Second application start address (stored in FLASH)

#define FLASH_APP3_ADDR 0x08030000//Third application start address (stored in FLASH)

accessories:

Function One: writes the flash space to the specified start address

APPXADDR: The start address of the application

APPBUF: Application code.

AppSize: Application Size (bytes).

void Iap_write_appbin (u32 appxaddr,u8 *appbuf,u32 appsize)

{

U16 T;

U16 I=0;

U16 Temp;

U32 fwaddr=appxaddr;//the address currently written

U8 *dfu=appbuf;

for (t=0;t<appsize;t+=2)

{

Temp= (U16) dfu[1]<<8;

temp+= (U16) dfu[0];

dfu+=2;//offset of 2 bytes

Iapbuf[i++]=temp;

if (i==1024)

{

i=0;

Stmflash_write (fwaddr,iapbuf,1024);

fwaddr+=2048;//offset 2048 16=2*8. So multiply by 2.

}

}

if (i) stmflash_write (fwaddr,iapbuf,i);//Writes the last bytes of content.

}

Function two: Jump to execute Flash

Jump to Application Segment

APPXADDR: User code start address.

void Iap_load_app (U32 appxaddr)

{

if (((* (vu32*) appxaddr) &0x2ffe0000) ==0x20000000)//check whether the top address of the stack is legitimate.

{

jump2app= (Iapfun) * (vu32*) (appxaddr+4); User code Area The second word is the program start address (reset address)

Msr_msp (* (vu32*) appxaddr); Initialize the app stack pointer (the first word in the user code area is used to hold the top address of the stack)

Jump2app (); Jump to App.

}

}

Function Three: Serial port interrupt Service function

if (Usart_getitstatus (USART1, usart_it_rxne)! = RESET)//Received Data

{

Usart_senddata (USART1, ' R ');

Res=usart_receivedata (USART1);

if (Usart_rx_cnt<usart_rec_len)

{

Usart_rx_buf[usart_rx_cnt]=res;

usart_rx_cnt++;

}

}

Global variables:

U8 Usart_rx_buf[usart_rec_len] __attribute__ (at (0x20001000));//serial receive buffer, maximum Usart_rec_len bytes, starting address is 0x20001000.

U16 Usart_rx_sta=0; Receive Status Tokens

U16 Usart_rx_cnt=0; Number of bytes Received