2022-06-30 07:23 AM
Hello,
I am trying to use the dual-bank boot feature in order to safely upgrade the software application.
The hardware configuration is the following:
I have a simple application that simply blinks a LED and does nothing else.
I have programmed both banks (@0x0800000 and 0x08080000) with this same application and checked the memory content to verify both banks are equal.
I can read in the bank's first address the stack pointer (0x20018000 in my case)
When BFB2=0, my application is running properly and I can see the LED blinking.
When BFB2=1, nothing happens, it seems I am stuck in the system bootloader....
I tried with BFB2=1 and the bank2 erased => same result, it doesn't work.
Thanks to the JTAG, I was able to make the following verifications:
Is there somthing wrong in my logic ?
Is there something else I can check ?
I am not using an evaluation board, is there a possibilty that the HW could causes this behaviour ?
Thanks for the help!
2023-02-24 03:21 PM
I'm having (I think) this same issue. Was this ever resolved?
My changes are that my applications are printing UART, and are slightly modified such that the first characters they print are different; and that I'm using the STM32L476 Nucleo board. I'm able to boot into Bank2, but that program resets before it gets to its main loop.
I'm currently trying to understand whether the solution is in the following from RM0351:
When booting from bank 2, the boot loader will swap the Flash memory banks.
Consequently, in the application initialization code, you have to relocate the vector table to
bank 2 swapped base address (0x0800 0000) using the NVIC exception table and offset
register.
2023-03-02 04:04 PM
I resolved my issue. The snippet from RM0351 above was indeed the solution. I simply had to do the following before my code had to service any interrupt (e.g. SysTick) if my code was running in Bank 2:
SCB->VTOR = 0x8000000;
Even easier, I actually just un-commented "#define USER_VECT_TAB_ADDRESS" in system_stm32l4xx.c. This effectively does the above on every boot. When booting from Bank 1, it essentially does nothing.
I suspect that your application is not stuck in the Bootloader. While my program was able to run for a little bit in Bank 2, I found that the Keil debugger would for some reason follow Bootloader execution. I think this was only some artifact of how the Bootloader and debugger interact.