Setting up STM32F765 for dual boot operation.

[murrellr]

I'm trying to set up our system for dual boot mode. I'm using AN4826 "STM32F7 Series Flash memory dual bank mode", AN2606 "STM32 microcontroller system memory boot mode", and sample program "STM32F769I_EVAL\Examples\FLASH\FLASH_DualBoot" as guides. I need some clarification on how to get this to work.

I am developing the program using Keil uVision 5.25.2.0. Using STMCubeProgrammer, I have nDBANK and nDBOOT unchecked. I have BOOT_ADD0 set to 0x80 (0x200000). I am using a SEGGER J-Trace PRO for flashing and debugging.

My intent is to execute from one bank and use the other bank for updates. On entry to my code, I will check the other bank to see if new code is present. If so, I want to change to booting into the other bank, invalidate the code in the current bank, and do a soft reboot. On reboot, I want to check if the other bank contains invalid code. If so, erase it to set up for future updates.

My current problem is that I always power up into the bootloader when trying to debug with j-Trace PRO.

First, I need some clarification from the documents.

1. The boot flowchart has a decision box that states "If boot address is out of memory range or in ICP".
   1. What is the memory range?
   2. What is ICP?
2. Another decision box states "If the code in boot address is valid"
   1. What constitutes "valid" code?
3. Is the value in BOOT_ADD0 affected by the flash bank swap bit SWP_FB? That is, if BOOT_ADD0 = 0x80 (0x200000) and SWP_FB is 1, will the bootloader execute the code at 0x300000?
4. And lastly, how do I debug my code using the SEGGER j-Trace PRO?

[thomfischer]

1.

The boot address must point to an address where there is real memory mapped to.

ICP = In Circuit programming.

In the flowchart Figure 46, if Boot add is "If boot address is out of memory range or in ICP", it goes to point

"Continue Bootloader execution", which means you have to follow Figure 47.

that means it executes the internal bootloaders e.g on UART or USB.

2.

at the boot address, there is stored the stack pointer which must point to some real ram address.

if this is not the case, it's invalid.

3.

I made some tests with dualbank mode and I have changed BOOT_ADD0 to boot either from bank1 or bank2.

   in figure 46 you can see, that the internal bootloader decides to swap the banks dependent of the boot add

   "if boot address is in Bank2"--> "Set Bank Swap to bank 2", so bit SWP_FB is set by the internal bootloader.   

to use dual bank mode,

run program from e.g. from bank 1,

update other bank2 with new application.

program BOOT_ADD0 to boot from bank2.

issue reset.

there is a bug in F7 internal Bootloader, it always uses only BOOT_ADD0,

that means you cannot use (BOOT0 Pin =1) BOOT_ADD1 to jump to the internal system bootloaders.

see AN2606 Rev 36 page 188

"When the Flash memory is configured to the dual

bank boot mode (nDBANK=nDBOOT=0),

whatever the BOOT0 Pin state only

BOOT_ADD0 value is considered (when BOOT0

Pin=1, BOOT_ADD0 value is considered not the

BOOT_ADD1).

Workaround: in order to manage dual bank boot

with BOOT_ADD0 only, please refer to the

AN4826: "STM32F7 Series Flash memory dual

bank mode�?

"

So if you want to use dual bank mode in F7, you cannot use the internal bootloaders (UART or USB) to

restore firmware.

You have to use SWD or JTAG to program flash in case your chip is bricked.

4.

For Segger, because of different flash memory layout in dualbank mode,

you need another flashloader algorithm, see https://wiki.segger.com/STM32F7

as alternative, don't use dual bank mode and program your own bootloader.