2012-10-02 10:00 AM
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!
2012-10-02 10:39 AM
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.2012-10-03 12:51 AM
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.
2012-10-03 04:08 AM
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