cancel
Showing results for 
Search instead for 
Did you mean: 

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.

AW
Associate II

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.

8 REPLIES 8
Bubbles
ST Employee

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.

TDK
Guru

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
Associate II

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.

AW
Associate II

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.

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.

GLASS
Senior

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...​

AW
Associate II

Thanks @JHOUD​ That was a good suggestion. I've greatly simplified the code and am not using interrupts for now and it's working fine. I'll gradually add my code back in and find out where I've gone wrong. Thanks again.

GLASS
Senior

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...​