Unreadable flash due to power failure

[AVlad.1]

We met with strange problem with STM32H743. 

Could you please advice how to diagnose the following bug/effect of built-in flash :

we use STM32H743 at our device. We calibrate the device within assembling procedure. 

The calibration data stored in built-in flash of the chip. 

But it was found that if the power is accidentally turned off while 

writing to the flash, this area of the flash becomes unreadable. 

The worst is that when we are trying to read this area, the chip gets into 

a hardfault probably.  

Then watchdog reboots the device and the device become a "brick", with 

endless rebooting. 

A test firmware has been prepared that does not read calibration

data at startup. Using the initial bootloader, it was loaded into the device.

Hardfault has ended.

When you try to read the calibration command in the device interface, 

hardfault occurs again.

If we force to clear the sector and write the calibration data by the 

command from host device, the flash restores its functions and works 

correctly. 

Please advice how to avoid it and how can we check flash memory to 

diagnose the failed sectors?  

[TDK]

> Please advice how to avoid it and how can we check flash memory to 

diagnose the failed sectors?  

Maybe adjust procedure so that power isn't turned off mid-write.

I would write a CRC to the start and end of the flash block. When you read it, if the CRC matches, you can be reasonably confident the flash is valid. If not, or if it hard faults, you need to erase that page.

I would be curious to know the nature of the hard fault you're getting and whether it's triggered directly by reading the flash or indirectly through using bad data in your code somewhere.

[AVlad.1]

This is a human factor. It will never be possible to predict when a person will turn off the device.

It's good that writing to flash occurs only at the stage of assembling the device and the malfunction is detected immediately.

Using the CRC will not correct the situation. Incorrectly read data is not terrible. In our case, it turns out that it is impossible to read any data. Any attempt to access this block of memory will crash the processor.

The question is how to programmatically determine such a damaged block of memory without crashing the processor. In this case, the program can format the block and report about incorrect data. At the same time, the device will remain operational. That will allow to repeat the recording of data and does not require more serious action.

[TDK]

Right, so detect that a crash has occurred and take actions upon restart to fix the block. Put data into SRAM prior to the reads that will let you diagnose why the chip has been reset and read that data upon startup. The RCC_CSR flags may also be helpful for detecting this.