Embedded development: tips and tricks -- clean jump from boot loader to application code

　　 The boot loader is included in almost every embedded system , It also provides a good way to update the application code in the field , Without access to the programming port . As important as the boot loader , Embedded developers often get errors when trying to jump from the boot loader to their application code . Jumping needs to be clean , But there are several factors that can cause problems , for example ：

　　l Write to register at one time ( For example, watchdog register )

　　l The clock is set

　　l Stack and program pointers

　　l Peripheral settings

　　 Developers can make a clean transition from boot loader to application code in two different ways . The first approach involves developers carefully matching their application code and bootstrap settings . for example , The developer will match the watchdog register 、 The clock is set , It may even match UART And other peripherals . The boot loader initializes all these components to a known system state , And simply leave the program execution to the application code . The problem with this is , Any changes in the application code also need to be made in the boot loader .

　　 The second and cleaner way to handle the jump between the boot loader and the application code is to follow a simple process , Restore any settings involved in the boot loader to their original reset state . This will include peripherals , Such as GPIO、 The clock , Even modify the stack and program counters . When embedded developers do this , The application code is completely unaware that another application is executing in memory , The only setting that needs to be matched is a register that can only be written once !

　　 Preparing to jump from the bootstrap to the application code is simple , Can be found below :

　　l Confirm that the application reset vector has been programmed

　　l Verify application checksums and security credentials

　　l Deinitialize the peripheral , And put it in the reset state

　　l Set the vector table register to apply the reset vector (ARM)

　　l Set the stack pointer register to the application start address

　　l Set the program counter to the reset vector ( Jump to application )

　　

 

　　 Let's briefly discuss each step . Before bootstrapping the loader to do anything , It needs to verify the integrity of the application . The first step is to verify that the reset vector has been programmed , And not 0xFFFFFFFF or 0x00000000. Usually , The erased flash memory sets all its bits , So if we see this state , The boot loader knows there is a problem , Should remain in the boot loader , This is a known security state . please remember , We assume that any programmed value between the two is correct , This may be a bad assumption , But it's good enough for today's embedded developers .

　　 Next , The bootloader should perform checksum calculations on the application space , To ensure that the application is effective . Again , If there is a problem during the update process , There may be a partial program with a reset vector , If there is no checksum , You can't know that . most important of all , The bootloader should also check for any digital signatures or security measures , To ensure that not only the application is complete , And the source is correct , It is not malware or modified programs .

　　 Once the boot loader verifies that the application is complete and from the correct source , It's time to return to the original state . Any touched non write once peripherals should be put back to their reset state . The best way to do this is to look at the drive you are using 、 Registers for driver initialization and access , Then look for these registers in the data book . Each data book shows the value of the power on reset register . For each modified register , They can be reset to these states . Usually , I will avoid changing the clock register 、 Watchdog and write once register . I just match these states between the application and the boot loader .

　　 here , The microcontroller returns to the reset state , And ready to run the application code . Before that , Need to update vector table register , To point to the location of the application's vector table , Instead of bootloader . The interrupt vector table can be located anywhere , Therefore, there is a need for coordination between the bootloader and the application linker file . for example , Embedded developers will write the following single line of code , among PROGRAM_FLASH_BASE Is the first vector table location of the application :

　　SCB _ VTOR =(uint 32 _ t)PROGRAM _ FLASH _ BASE;

　　 Once you've done this , It's time to jump to the application . Developers can jump from the bootloader to the application in several different ways . One way is to simply dereference the application's reset vector position . The problem with this is that the stack pointer may not be in the correct position , Which leads to strange behavior . Ideally , The developer sets the stack pointer , Then set the program counter . How this is done will vary from microcontroller to microcontroller . You almost always need to use inline assembly code to accomplish ( This is the only time I advocate writing assembly code ). about ARM Micro controller , Here's a sample code snippet :

　　void Flash _ start application(uint 32 _ t start address)

　　{

　　asm(" ldr SP,[r0,# 0]");

　　asm("ldr PC,[r0,# 4]");

　　}

　　 Depending on the compiler used , The exact code will be slightly different . Inline assembly is not C standard , So each compiler vendor implements it in a different way , Or, in some cases, not at all ! Let's see what's going on .

　　 To minimize assembly language code , Wrap assembly language code in C Function is crucial . The reason is that startAddress Be passed on to Flash_StartApplication Time in function , It is automatically stored in the register r0 in . With this knowledge , There is no reason to add additional assembly language instructions to load the required start address into the register .( Yes , It saves us an assembly instruction , But it's also easier to maintain , More flexible ). then , The first assembly instruction is to get the information stored in the register r0 The middle offset is 0(# 0) Value , And copy it to the stack pointer (SP) register . then , The second instruction tells the processor to r0 Add the offset to the value stored in 4 (#4), And copy it to the program counter (PC) In the register . Offset 4 It's actually going to be r0 Add to the value stored in 4. The next instruction executed will be the reset vector of the application code . We have just successfully entered the application !

　　 This is all ! Follow this process , Embedded developers can now easily jump from the boot loader to your application code , And make sure it will work the way you want it to .