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.

[AVlad.1]

I think it's a good idea. I can even do without restarting the processor if I analyze the error in the hardfault handler.

I will try to implement this. Although there is probably a nicer solution ;-)

[AVlad.1]

I, too, have not yet understood the nature of the hard fault. I cannot examine it with a debugger, because the flash is protected. With the help of programming through the bootloader and test firmware, it was possible to localize the place in the program where the processor is rebooted. Unfortunately, I repaired all 3 devices with a damaged flash while investigating the problem. Now I have nothing to conduct research on the nature of the defect.

If there is still such a device, I will take it for research and write a special firmware for it, which will show which memory areas are available for reading, which cause a hardfault.

I'm not even sure if the processor gets into a hardfault, there may be some other reason why the processor is rebooted. Judging by the period of reboots, the watchdog timer is triggered.

But I can say for sure that a reboot occurs when you try to read a memory cell at an address from a flash. Moreover, the program does not matter what value it reads from the flash. The value will not affect the operation of the firmware. Only the operation of reading a constant from the flash leads to a reboot.