STM32G4 Flash writes at BOR

[brumbarchris]

Hello,

We have currently moved on to the STM32G4 series, and we are now looking at a project where data will be occasionally written to flash under control of our own code. Of course, this exposes us to flash memory corruption during unforeseen power loss events. To protect against this, I intend to use the internal Power Supply Supervisor block of the microcontroller.

I am tempted to directly use the BOR threshold to protect us, so that the microcontroller gets reset as soon as the voltage drops under some 2.9V. This will still give us some time (based on on-board capacitance discharge time) until the voltage drops below the 1.7V minimum operating voltage so that the eventual flash memory write operation would have time to finish. We plan to write a maximum One row (32 double word) at a time, so the micro power supply has to be able to remain above the 1.7V threshold for 2.7ms, which is the maximum t_prog_row value. Whereas I can ensure such a low decay of voltage, with sufficient on-board capacitance, it is unclear to me if already started flash write operations are allowed to finish in case a BOR occurs. Do you know if this is the case?

I have seen in other documents indications that the PVD (Programmable Voltage Threshold) must be used to detect a falling supply voltage and to trigger an interrupt, which would then allow the micro to not initiate any other flash writes. But this would take some considerable time, I suppose, and it is software dependent.


Edit (I am hijacking my own thread!): just as a side note, we also have a winbond W25Q64JVSSIM SPI memory connected to the micro. This has a "write inhibit threshold voltage" of 2V. So I suppose, it would not initiate a write if the voltage would be below this threshold. But what would happen if a write command has been clocked in just before the falling supply reached the 2V and consequently a flash write was initiated? Would it also experience corruption when the voltage would eventually cross this threshold, with the write in progress? I was only able to identify some potential corruption scenarios in its datasheet concerning a erase/program suspend situation, but this is not something we intend to use.

Best regards,

Cristian

[harerod]

Each device's datasheet states the conditions required for correct operation. If during any operation these conditions are not met, the device's behavior becomes undefined.
So in the case of brownout handling, your setup, combining hardware and firmware, must ensure that those conditions are met during the whole duration of any operation.
You mentioned board buffer capacitance. This must be large enough to ensure adequate supply voltage between brownout detection and end of memory operation. Depending on other consumers on the board, it might be easier to give the MCU and/or memory device their own supply island. Just extend the usual EMI countermeasures.

To make things even more interesting, there are different possible error scenarios. A classic is the corrupted write pointer. Modern designs (as the STM32 family) try to mitigate this by using key sequences for write access. Another possible problem might be power loss during write and corrupted memory contend at the address written.
A comprehensive solution to the whole issue might have to consist of several layers of protection and verification. The latter might consist of the usage of checksums or key values to be checked after the next power up. In this context, one interesting feature of FLASH memory is that single bits may only be turned from 1 to 0, while reset to 1 requires a sector erase. Keeping all this stuff in mind can make FLASH writes pretty foolproof. In a current design I run a proprietary, wear leveling file system in an STM32F4, expected device lifetime in continuous operation should be well beyond 10 years.   

[uer166]

I have seen in other documents indications that the PVD (Programmable Voltage Threshold) must be used to detect a falling supply voltage and to trigger an interrupt, which would then allow the micro to not initiate any other flash writes. But this would take some considerable time, I suppose, and it is software dependent.

I would recommend using PVD with a high-ish threshold (say 3V for a 3.3V rail). And keep the BOR at the lowest value. That way you have a window between 3V and 1.9V (or whatever you set the BOR to) to write to flash. You need enough holdup capacitance to have enough time, but it's certainly not hard to accomplish. We have used this approach on STM32G4 with some success.

[harerod]

Just to put this issue into perspective (using STM32F407 datasheet for my convenience):
- Word (8/16/32bit) programming time is 100µs worst case
- interrupt latency should be< 1µs (assuming that one got the priorities right)

So the buffer time needed to avoid write corruption is around 100µs. In combination with the secondary firmware measures that I described earlier, avoiding FLASH corruption in the STM32 family shouldn't be a problem.
I checked several datasheets. The PVD might be missing in some lower end devices (i.e. present in STM32F051, yet missing in STM32F030x4-C ).

[brumbarchris]

Hello, and thank you for your replies!
This is the flash write time from our datasheet, this is where I have taken the 2.7ms from:


This, of course, supposing we would not do individual writes on entire pages, or banks...

I would recommend using PVD with a high-ish threshold (say 3V for a 3.3V rail). And keep the BOR at the lowest value. That way you have a window between 3V and 1.9V (or whatever you set the BOR to) to write to flash. You need enough holdup capacitance to have enough time, but it's certainly not hard to accomplish.

Ah, this would have been my proposed approach, but our SW Engineer is telling me that all interrupts are disabled during flash write operations, so that the micro would not be able to trigger the interrupt on the high-ish PVD threshold. I'll have to investigate if this is really the case; I have been looking through AN4894 Application note EEPROM emulation techniques and software for STM32 microcontrollers, and whereas it does mention that interrupts cannot be served during a maximum time equal to the longest page-erase operation duration, this only refers to the situation where the emulated EEPROM is in the same bank with the ISR code (The provided implementation of the EEPROM emulation firmware runs from internal Flash memory, thus accesses to the same Flash bank are stalled during Flash erase or programming operations )

So I guess that if we are carefull and place the EEPROM emulation in a different bank from the interrupt service code, we could service the PVD interrupt.

Moreover, in the same application note they indicate in chapter 5.1.1 a key feature of this EEPROM emulation in the internal flash as being possible interrupt servicing during program and erase operations. So I guess servicing interrupts during flash write operations should be somehow possible.

In the same app note I also came across some other interesting statement: The EEPROM emulation software has been designed to be robust against power failures and fully asynchronous resets. Not sure what "robust" means, but it does not sound like a "guarantee".

Best regards,
Cristian

[brumbarchris]

Digging further in this AN4894 Application note EEPROM emulation techniques and software for STM32 microcontrollers, I did come across the answer to my exact original question ( it is unclear to me if already started flash write operations are allowed to finish in case a BOR occurs. Do you know if this is the case?).

In chapter 6.2 Detecting power failures they state the following:

The decoupling capacitors or battery must be sized to provide enough power to the chip during the full write or erase operation and before the supply voltage goes below 1.7 V (minimal operating voltage) or before a BOR (Brown Out Reset) is generated.

So a BOR will disruptively interrupt an ongoing internal flash write.

Best regards,
Cristian

[uer166]

So I guess that if we are carefull and place the EEPROM emulation in a different bank from the interrupt service code, we could service the PVD interrupt.

Moreover, in the same application note they indicate in chapter 5.1.1 a key feature of this EEPROM emulation in the internal flash as being possible interrupt servicing during program and erase operations. So I guess servicing interrupts during flash write operations should be somehow possible.

Why do you care if flash writes stall the CPU? If you're only writing to flash in the PVD interrupt it'll simply stall the executing code (but you're already doing that in software anyway with a while(flash_write_done_flag{})! If you are writing to flash in the application, then you for sure need to execute from a different bank since it seems that it'll stall your whole app, not just the PVD interrupt.

[uer166]

So a BOR will disruptively interrupt an ongoing internal flash write.

A BOR will disruptively interrupt ongoing everything, since it physically puts CPU into reset, not just flash writes.

[brumbarchris]

Why do you care if flash writes stall the CPU? If you're only writing to flash in the PVD interrupt it'll simply stall the executing code

It is the other way around: our SW engineer is concerned that the interrupt will not fire if a PVD event occurs during an ongoing flash write.

BR,
Cristian

[uer166]

Why do you care if flash writes stall the CPU? If you're only writing to flash in the PVD interrupt it'll simply stall the executing code

It is the other way around: our SW engineer is concerned that the interrupt will not fire if a PVD event occurs during an ongoing flash write.

BR,
Cristian

He would probably be correct if you're doing it in the same bank, I mean the whole CPU would then get stalled waiting for instructions, not just the PVD interrupt like I mentioned. Just do it in the other bank, or don't write to flash anywhere outside the PVD interrupt.

[brumbarchris]

That is also my point: it's doable. But I have a lot of convincing to do to implement a solution for a problem that is not yet apparent...

Regards,
Cristian