Posted on June 06, 2014 at 21:06
Thanks for another very helpful answer, Clive! The addition of the ROM remap does indeed fix the issue. I agree with your previous posts that jumping to the ROM bootloader from a reset is the best way to go--no special ''system takedown'' needed!
We use IAR Workbench, and a C++ function as the reset handler, so I'd like to share how we perform this check. We carve out a RAM location with the linker command file that will not be subject to modification by startup (ie. not in .bss, .data, etc). These sentries are written by the app, and evaluated at reset. If they indicate a reboot request, we clear them, and away we go!
The code for the reset handler:
void __iar_program_start()
{
if ((*(BOOT_SENTRY_1_ADDRESS) == BOOT_SENTRY_1) &&
(*(BOOT_SENTRY_2_ADDRESS) == BOOT_SENTRY_2))
{
*(BOOT_SENTRY_1_ADDRESS) = ~BOOT_SENTRY_1 + 1;
*(BOOT_SENTRY_2_ADDRESS) = ~BOOT_SENTRY_2 + 1;
enter_bootloader();
}
__disable_interrupt();
__iar_init_vfp();
__cmain();
}
And the bootloader jumper file:
MODULE bootloader_iface
SECTION `.text`:CODE:NOROOT(2)
PUBLIC enter_bootloader
enter_bootloader:
LDR R0, =0x40023844 ; RCC_APB2ENR
LDR R1, =0x00004000 ; enable SYSCFG clock
STR R1, [R0, #0]
LDR R0, =0x40013800 ; SYSCFG_MEMRMP
LDR R1, =0x00000001 ; remap ROM at zero
STR R1, [R0, #0]
LDR R0, =0x1FFF0000 ; load ROM base
LDR SP,[R0, #0] ; assign main stack pointer
LDR R0,[R0, #4] ; load bootloader address
BX R0
END
Thanks again, Clive!
