STM32F4 Custom Bootloader & Interrupts

[phil239955_stm1_stmicro_com]

Posted on October 02, 2012 at 19:00

I think this should be fairly straight forward, but so far it has tripped me up and now the solution is evading me.

I have a custom Bootloader which is located in the base memory of the User Flash. Depending on input it may thenread a firmware upgrade from the USB interface and Flash the User Flash higher sectors with new firmware. Finally it checks for the application in the corect location in the User Flash before jumping to it using the following function:

static
void
Boot_ApplicationImage( 
void
) 
{ 
// Typedef 
typedef 
void
(*pFunction)(
void
); 
// Function Pointer 
pFunction Jump_To_Application; 
// Jump Address 
uint32_t JumpAddress; 
/* Jump to user application */
JumpAddress = *(__IO uint32_t*) (APPLICATION_ADDRESS + 4); 
Jump_To_Application = (pFunction) JumpAddress; 
/* Initialize user application's Stack Pointer */
__set_MSP(*(__IO uint32_t*) APPLICATION_ADDRESS); 
Jump_To_Application(); 
}

This all works fine. HOWEVER... in my Bootloader I setup SysTick, and configure a SysTick handler that increments one variable (as a millisecond tick counter), and also decrements another variable if it's current value > 0. When I jump from theBootloader to my Application it seems that the SysTick is still running and still being serviced; the 1st memory location still gets incremented every millisecond, and the 2nd memory location still gets decremented whenever it has any value in it >0. Of course the problem with this is that the Application doesn't know that the Bootloader is still accessing these memory locations, and so stores it's own data in the locations which obviously gets corrupted 1ms later. Just before leaving my Bootloader code how do I 'unregister' the SysTick handler code so that the Bootloader relinquishes full control to the Application once the jump is made? Many thanks!

[Tesla DeLorean]

Posted on October 02, 2012 at 19:39

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/Bhccjgga.html

SysTick->CTRL &= ~(SysTick_CTRL_TICKINT_Msk   | SysTick_CTRL_ENABLE_Msk); Other interrupts disable via the NVIC. That, or you could relocate the vector table to point to the application.

[phil239955_stm1_stmicro_com]

Posted on October 03, 2012 at 09:51

Thanks for your reply Clive.

Please can you elaborate on your closing comment; ''That, or you could relocate the vector table to point to the application.'' In my Application code, in the system_stm32f4xx.c source file I have uncommented & set the vector table offset line;

#define VECT_TAB_OFFSET 0x20000 /*!< Vector Table base offset field.

Which is then used later in the same file;

/* Configure the Vector Table location add offset address ------------------*/
#ifdef VECT_TAB_SRAM 
SCB->VTOR = SRAM_BASE | VECT_TAB_OFFSET; 
/* Vector Table Relocation in Internal SRAM */
#else 
SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; 
/* Vector Table Relocation in Internal FLASH */
#endif 

It is the relocation in Internal FLASH that I am using. Is there something additional I should be doing, with regard to your closing comment? Thanks again.

[phil239955_stm1_stmicro_com]

Posted on October 03, 2012 at 13:08

Well... annoyingly the issue seems to have gone away.

This morning I have re-compiled my code (for both the bootloader and the application) and reloaded both. I have checked that the various variable are still using the same memory locations, and yet now when the jump is made from Bootloader to Application, once the Application hits its 'main' the memory has been re-initialised to zero, and the memory location that contains the millisecond counter of the bootloader no longer increases. As I recently updated to uVision 4.60 I even took the step of installing 4.54 on another machine to see if that was having an effect. As of this point in time I am unable to reproduce the problem, but I shall continue to 'look out for it'. Thanks