Flash erase stall on STM32H753 and servicing an external watchdog

[TSosi.1]

Hi,

I need to service an external watchdog when a flash sector is being erased. The sector being erased is in the same flash bank where code is executed from. Before I try to jump and run from RAM I had a few questions.

Where is flash stall discussed in the reference manual?

Given the chip architecture, is there any issue with toggling a pin on Port G when a sector erase is ongoing? In other words, is the AXI bus matrix stalled during a flash erase?

Thanks!

 

[Pavel A.]

> is the AXI bus matrix stalled during a flash erase

No, flash erase alone is not causing bus matrix stall.

[Tesla DeLorean]

>>Where is flash stall discussed in the reference manual?

I don't know, but it's a common phenomenon I can date back until at least the early 1990's, perhaps late 1980's, related to NOR Flash implementation. So Established Lore

ST's solution is to use the Flash's "Busy/Ready" to stuff wait-states to hold off the processor, when something tries to touch flash memory whilst it is unavailable. One could perhaps have used a mutex/semaphore at a software level, for code running outside of the flash, but it's a coding nightmare to enforce, what with interrupts, blocking functions and libraries / call-trees no one is interested in understanding. An alternative would be for the MCU to fault, allowing for code to support a retry later, or defer to other tasks/threads, but most anything hard in the code is provided as a while(1) these days.

Have your entire core run from RAM, don't touch or look at FLASH whilst busy, and use a MUTEX/SEMAPHORE to control ownership access so the MCU doesn't have to use the "Ban Hammer" to enforce for you.

ST's failing here is stupidly large sectors, and erase times, relative to watchdog, and real-time service expectations of nearly every other peripheral. Could have been far better partitioned and banked in my opinion to contain the impact, but that takes design work, and transistors.

[Piranha]

The huge 128 KB sectors on H7 are terrible also because of memory waste. If the project requires a bootloader, a 128 KB are immediately reserved. Does it require saving of user data? Add another 128 or 256 KB. Eventually you have to reserve 384 KB, which cannot be used for the main firmware, but in reality a few tens of KB would be more than enough for those purposes.

F2/F4/F7 series at least has the first bigger sector split up into 4+1 smaller ones, which gives some reasonable flexibility.

[TSosi.1]

Thanks for the responses. What is curious is on a previous version of the software with the exact same hardware, the external watchdog strobes were occurring on the pin during a flash sector erase. We moved to new firmware including a new HAL and now there is a dead time of 848 ms.

[Pavel A.]

Anyway, you're going to run from RAM or from other bank in order to prevent the stall.

The sector size is not relevant here.

Have you tried this? Does it solve the problem?

[TSosi.1]

No, but I wanted to check if anyone else ran into this problem where it used to work and now it doesn't. Also, I wanted to check if the AXI bus matrix is affected, because if it is then running from RAM will not work.

[Pavel A.]

Does this issue look similar?

[TSosi.1]

Follow up on this question. When we jump and run from RAM we are able to service the external watchdog. Thanks for your help!

[AlexKern]

Not in any case. Here F427, external WD ~70ms cycle. The task serving it runs from RAM with 10ms cycle and all seems to be healthy, untill we are starting to erase flash. I gon't know is it related to OS implementation or not, but our 10ms sleep mutates to 2 seconds.. And we got killed by WD.