Skip to main content
AW_it
Associate II
July 22, 2021
Question

I'm using an stm32f429 2MB dual bank mcu and erasing a sector in flash bank2 from code running in bank1. I can't achieve this without the code in bank1 stalling. I can't find any documentation relating to the stm32f429 2MB to allow this.

  • July 22, 2021
  • 5 replies
  • 1915 views

For the  stm32f429 1MB dual bank there is documentation relating to setting dual bank mode, and for the  stm32lxxx there is documentation relating to setting dual bank mode, but not for the stm32f429 2MB dual bank. I'm wondering now if read-while-write is actually supported on the stm32f429 21MB dual bank mcu. I'd appreciate if anyone can explain this further. Thanks.

This topic has been closed for replies.

5 replies

Bubbles
ST Employee
July 22, 2021

Hello @AW​ ,

in the RM0090 (rev.19) in chapter 3.6 there is a paragraph on page 84:

>On STM32F42xxx and STM32F43xxx devices, two banks are available allowing read

>operation from one bank while a write/erase operation is performed to the other bank.

Is it possible that the stall is caused by the BSY bit?

J.

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
AW_it
AW_itAuthor
Associate II
July 23, 2021

Hi J

Thanks for your suggestion. I am waiting for the BSY bit to clear before I erase:

while (__HAL_FLASH_GET_FLAG(FLASH_FLAG_BSY)) {}

Status = HAL_FLASHEx_Erase_IT(&EraseInfo);

I'm using the HAL btw.

My code is in bank1 sectors 0 to 5. If I erase any of the bank2 sectors 12 to 23 the stall is exactly the same as if I erase any of the bank1 sectors 6 to 11, where I'd expect the stall.

I realise now the stm32f429 2mb is always in dual bank mode. The BSY bit is clear, and the erase does happen as expected. It's hard to imagine what I'm missing.

I did try erasing the whole of bank 2 using mass-erase, but the stall is still there.

I'll keep reading and trying to understand what (probably obvious) step I'm missing.

Thanks again.

Bubbles
ST Employee
July 23, 2021

Hello @AW​ ,

I cannot think of any obvious reason why it shouldn't normally work. There are no known errata in the flash and the F4 is a mature product.

I'd suggest to try experimenting with flash erase using a simple code (the FLASH_EraseProgram example from the Cube package is a good starting point. Just change the address range to something related to your case and try again.

Rgds,

J

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
TDK
July 22, 2021

I do this on the STM32F429 2MB and never ran into this issue. I erase all of bank 2 from code running in bank1.

"If you feel a post has answered your question, please click ""Accept as Solution""."
AW_it
AW_itAuthor
Associate II
July 23, 2021

Thanks both for your comments. I am waiting for the BSY bit to clear before I erase:

while (__HAL_FLASH_GET_FLAG(FLASH_FLAG_BSY)) {}

Status = HAL_FLASHEx_Erase_IT(&EraseInfo);

I'm using the HAL btw.

My code is in bank1 sectors 0 to 5. If I erase any of the bank2 sectors 12 to 23 the stall is exactly the same as if I erase any of the bank1 sectors 6 to 11, where I'd expect the stall.

I realise now the stm32f429 2mb is always in dual bank mode. The BSY bit is clear, and the erase does happen as expected. It's hard to imagine what I'm missing.

I did try erasing the whole of bank 2 using mass-erase, but the stall is still there.

I'll keep reading and trying to understand what (probably obvious) step I'm missing.

Thanks again.

GLASS
Visitor II
July 23, 2021

Hi, we also use dual bank on stm32f439 2mb Flash without execution stalling. You need to give a look at option bytes (dual bank mode​). If you are using dual bank mode and use bank swapping, @0x08000000 and 0x08100000 can be easily be swapped but when erasing sectors the sectors # are not swapped...

Other trap : debugger don't like bank swapping...​

GLASS
Visitor II
July 26, 2021

You can also try to catch ​ with debugger incorrect try to access @0x00000000. It's current error. I remember for example a friend who temporary commented mx_init_iwdc() call, but ommited to comment also each call to rearm watchdog. So handle is not valid and an invalid write access to null pointer...resulting in flash ctrl busy flag (occured on Stm32L496). Was a nice catch...

Hope it will help...​