So I found this handy file
sector_storage_h7xx.h in the repo and I’ve been using it to save cal/state data for a project I’m working on with the stm32h7. It works great most of the time but every once in awhile (sometimes weeks or days apart) a small part of the flash memory where the state is stored will get corrupted, the flash double error correction codes are tripped, and a hard fault occurs, causing the program to stall.
Trying to figure out why it’s happening and how to snap back from it… maybe a brown out reset? Flash has guaranteed behavior down to 1.6V and I’m not setting the BOR bits so the processor doesn’t trigger a reset until 1.6V. Maybe raising that reset threshold would prevent it.
Thought I’d post here and see if anyone had a similar experience or any tips/ideas.
I have seen it a couple of times on modules returned to me without having managed to successfully reproduce it myself.
The BOR bits is a good place to investigate!
I was worried I was the only one thank you for the validation! I’ll run with that for now and see how it goes. Here are some notes in-case someone has any interest in going down this path eventually.
From the datasheet, it seems the flash is good down to 1.62V:
but during a power down the level at which a reset is triggered can be as low as:
The probability may be low that a flash write would occur in this narrow range but probably best to raise the reset level above the minimum flash level.
The flash option bytes can modified using ST’s stm32cube programmer tool or the HAL. The flash peripheral modifies the bytes if they’re different from the requested change, so I think this can be called every time at startup:
//Set BOR to level 3 if it hasn't been set yet
HAL_StatusTypeDef val = HAL_FLASH_OB_Unlock();
flashConfig.OptionType = OPTIONBYTE_BOR;
flashConfig.BORLevel = OB_BOR_LEVEL3;
val = HAL_FLASHEx_OBProgram(&flashConfig);
val = HAL_FLASH_OB_Launch();
val = HAL_FLASH_OB_Lock();
Its been a week since I changed this and so far so good. I’ll report back if it happens again after doing this. I worked at a company using ATSAMs and we had returns all the time because of corrupted flash. A re-design with an external BOR monitor circuit resolved it.
Turns out none of the things above fixed the issue.
My new theory is that my WRHIGHFREQ settings are incorrect. For the STM32H743, the programming delay setting is not set by the HAL and it defaults to 0x3 aka both bits are set.
If we check the manual for the H743, this setting is not defined. Maybe 0x3 leads to more delay, which is OK or maybe it is undefined and causing issues. I guess I’ll try this and see how it goes.