STM32F765 / Flash / Start address of bank 2 / problem with RM

[Christophe Beugnet]

I've been experimenting with STM32F765VGT6 (custom board made by a colleague) and STM32F769NIH6U (on a STM32F769I-DISCO).

Please correct me as soon as you see a mistake.

I did not "play" a lot with the F769. As long as I did, everything seemed as expected.
I'm focused on the F765 now, with which I have problems.

Both MCUs Option Bytes are configured in 2 banks mode : nDBANK is unchecked.

Flash size :

- the F765 has 1 MB :

- the F769 has 2 MB

Bank 2 start address, as from RM :

- F769 : 0x08100000

- F765 : 0x08080000

Problem : I found it impossible to flash my code at 0x08080000 on the F765.

STM32CubeProgrammer returns :

15:52:48 : Opening and parsing file: MCU_F765_LwIP_NoFreeRTOS-0.1.0-0x08080000-0080E10666A0.bin
15:52:48 : Memory Programming ...
15:52:48 : File : MCU_F765_LwIP_NoFreeRTOS-0.1.0-0x08080000-0080E10666A0.bin
15:52:48 : Size : 120.95 KB 
15:52:48 : Address : 0x08080000 
15:52:48 : Erasing memory corresponding to segment 0:
15:52:48 : Erasing internal memory sectors [12 16]
15:52:49 : Download in Progress:
15:52:49 : File download complete
15:52:49 : Time elapsed during download operation: 00:00:01.546
15:52:49 : Verifying ...
15:52:49 : Read progress:
15:52:50 : Error: Data mismatch found at address 0x08084001 (byte = 0xF0 instead of 0xFA)
15:52:50 : Error: Download verification failed

But it is possible to flash and run at 0x08100000 :

15:55:24 : Opening and parsing file: MCU_F765_LwIP_NoFreeRTOS-0.1.0-0x08100000-0080E106669E.bin
15:55:24 : Memory Programming ...
15:55:24 : File : MCU_F765_LwIP_NoFreeRTOS-0.1.0-0x08100000-0080E106669E.bin
15:55:24 : Size : 120.95 KB 
15:55:24 : Address : 0x08100000 
15:55:24 : Erasing memory corresponding to segment 0:
15:55:24 : Erasing external memory sector 8
15:55:25 : Download in Progress:
15:55:26 : File download complete
15:55:26 : Time elapsed during download operation: 00:00:01.256
15:55:26 : Verifying ...
15:55:26 : Read progress:
15:55:26 : Download verified successfully

Using debug traces, displaying compile time and dates, etc, and swapping the boot addresses BOOT_ADD0 <--> BOOT_ADD1, I've been able to verify that I can run two different FWs, one at 0x0800000, the other at 0x08100000

I never tried 0x08080000 since flashing is impossible there.

So here's my question: is the start address 0x08080000 an error in the RM rm0410-stm32f76xxx-and-stm32f77xxx-advanced-armbased-32bit-mcus-stmicroelectronics.pdf ? (page 90 out of 1942)

Can I definitely rely on Bank 1 = 0x0800000 / Bank 2 = 0x0810000 ?

Is there an updated document, something I missed that confirms that ?

Or is it worse: did I mess with something and Bank 2 should be at 0x0808000 anyway ?

[Christophe Beugnet]

Please help.
I'm more confused than ever.

I did not noticed before. In the "Erase flash memory" tab, CubeProg shows a list of "Start Address" in accordance to the RM, especially, the first sectors of bank 2 is at 0x08080000 :

I can erase bank 2, i.e. the selected sectors on the picture above.

But when trying to program actual code à 0x08080000, I always get an error, like the one in my initial post.

I can flash and run code only at 0x08100000, although today, flashing at this adress may sometime result in an error too, before eventually succed.

[STOne-32]

Dear @Christophe Beugnet ,

I will move this thread To CubeProgrammer Community Board . As I see this log :

“

15:52:49 : Read progress:
15:52:50 : Error: Data mismatch found at address 0x08084001 (byte = 0xF0 instead of 0xFA)
15:52:50

”

Most probably my hypothesis is on the way CubeProgrammer is handling the dual bank mode for 1Mbytes to have 2 banks of 512K which is properly managed in the 2 MBytes  and not a silicon or product issue  to be investigated by my colleagues @Aziz BRIGUI 

regards,

STOne-32

[Aziz BRIGUI · Accepted solution]

Hello Christophe,

Thanks for your detailed analysis !  

Bank 2 should start at 0x08080000 for the 1MB part. This is just an issue in bank 2 erase coming from the Flashloader used by STM32CubeProgrammer. We are already aware of this (Internal tracking number: 188863) and the issue will be officially fixed in the next STM32CubeProgrammer release.

In the meantime, I've sent you some steps to follow to be able to workaround the issue with the current release.

Hope it helps !

Aziz