cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F7 dual boot question

DarkTaipei
Associate II
Posted on September 28, 2017 at 18:58

I am using STM32F767 and I can't understand the dual boot behavior of the board. 

I read AN2606. and for Fig 46. the flow chart of Dual Bank Boot implementation:

When nDBANK = 0 && nDBOOT = 0, it should boot either from bank 1 or bank 2, if the address is valid. 

if not, since the read protection = 0, so it will go to bootloader and in my case, the DFU mode. 

I use ST-link utility to play around the option status, and I found:

When nDBANK and nDBOOT is checked (= 1). It go straight to boot my program from flash

and if I unchecked nDBANK and nDBOOT, it went to DFU mode instead of booting from flash.

It seems totally opposite to the description of what AN2606 stated. The attachment is the screen print when both nDBANK and nDBOOT are unchecked. it went to DFU mode on each reset of the chip.

Also, the even more serious question: We used to use STM32F42x. Which if Boot0 pin is 1, then it goes to boot loader. if Boot0 pin is 0, then it will boot from different bank depend on BFB2 bit in options bytes. 

So, in case of a corrupted flash image, we can always push a bottom that make boot0 high and reload image from DFU.

For STM32F7 and AN2606. it seems that when nDBANK = nDBOOT = 0. as long as the address is good. there is no way to force the chip to DFU mode. So, when the image is corrupted, we will brick the chip and the only way out is connect through JTAG.

Anyway to force to bootloader in this case?

Tonyy.

2 REPLIES 2
DarkTaipei
Associate II
Posted on September 28, 2017 at 23:02

I think I found part of the answer. From AN2606. There is a fine print.

'When the Flash memory is configured to the dual bank boot mode (nDBANK=nDBOOT=0).

Whatever BOOT0 Pin state only BOOT_ADD0 value is considered....'.

Basically, Boot0 pin as well as BOOT_ADD1 value are useless in STM32F7. 

Yuri Andrade Rodrigues
Associate II
Posted on February 19, 2018 at 23:35

Hi Tonny,

I have the same question. I don't know if you could find a workaround for it, but I noticed the latest bootloader documentation (this month) says the same issue.

I created this topic and you can follow for further information:

https://community.st.com/0D50X00009XkWhoSAF

I hope we can have any solution coming soon.