STM32H573 in-application programming using the dual bank approach

[saeedraf]

Hi, I'm following the steps on the reference manual to perform in-application programming by first writing the new firmware to bank 2 and then swapping the banks after doing some checks.

After completing the steps and performing a software reset, the new firmware was updated. However, after closing the st-link debugger and reopening it, the debugging session immediately closes. I'm trying to figure out why. 

I have written the new firmware starting at address 0x0810 0000 according to the following:

I was wondering whether I need to offset by a couple sectors from the 0x810 0000 start address before flashing new firmware. Please let me know I'm mistaken, thanks.

[Tesla DeLorean]

Well if you have common code at 0x0800000 and 0x08100000 you can at least fork() between the two regions with the bank switch. Perhaps a couple of KB for a loader/recovery method.

You need to link the image for the address it's going to physically execute, not necessarily where you have it parked before it's swapped around.

[saeedraf]

Thanks for your helpful response! And, I'm assuming that I have to update the vector table offset to point to the new firmware location at 0x0810000 (i.e., starting address of bank 2), right? Thanks again.

[Tesla DeLorean]

To execute at 0x08100000 the Vector Table would need to reflect that in it's content, or you can move a fixed-up copy in RAM and point SCB->VTOR at that. 512-byte aligned.

But if you use the SWAP_BANK method to map the active image at 0x08000000, the vectors and table would need to built for that address

ie you build/link the content for 0x08000000, your update/park the FLASH at 0x08100000, at next boot you determine the most up to date firmware, at map it via SWAP_BANK

[saeedraf]

I'm still having issues with this; there is a flaw in my implementation that I'm failing to identify. 

My current implementation is doing the following (in the order provided):

1. Write new firmware to the start address of Bank 2 (0x0810 0000). I'm reading back the contents of the memory locations that I wrote to and I have verified that they are correct. 

2. Then, I followed the instructions, provided on p265 of RM0481 Rev 2, to change the SWAP_BANK bit to apply a new firmware update. 

3. Finally, I update the vector table offset SCB->VTOR = 0x0810 0000 before locking option control registers access and flash control registers access. However, the program terminates when the SCB->VTOR = 0x0810 0000 line executes, and the lines responsible for locking the flash are not executed.

After the final step, the new firmware was successfully uploaded based on the print statements in my serial console. However, debugger mode terminates immediately. When I try to debug again, I get the following in the debug console and I can't program/debug the micro anymore:

Remote communication error. Target disconnected.: Arg list too long.
GDB session ended. exit-code: 0
GDB never responded to an interrupt request. Trying to end session anyways

Based on the debug console, there seems to be an issue with servicing a specific interrupt. I thought that updating the vector table offset would solve the issue, but it did not. Any further guidance would be appreciated. 

[Tesla DeLorean]

The Vector Table enumerates literally dozens of ABSOLUTE ADDRESSES of functions deeper into the image.

Changing SCB->VTOR will point at a new table, and ALL active interrupts will then pivot through addresses in the NEW table, whether you're ready to deal with them or not.

a) Look at what Interrupts you currently have active.

b) Dump the content of the Vector Table

SWAP_BANK allows you to play slight-of-hand, so you can have TWO images designed to run at 0x08000000 and chose which one is active.

[saeedraf]

I see. I thought that changing the vector table offset via SCB->VTOR will take effect after a system reset, but that doesn't seem to be the case--updating SCB->VTOR restarted the micro instantly. I wonder whether SCB->VTOR was overwritten again by the SystemInit() function to 0x08000000. What do you think? I think I'm mixing up the order of instructions. Thanks again.