STM32H7 Flash Memory Corruption During Read/Write

[AAgar.2]

I have a custom bootloader in my application. This bootloader write some data in one of the sectors in the STM32H7, lets call this data "bootloader flash data".

This bootloader flash data is written to/read from multiple times during DFU, and to get into bootloader mode, etc.

Whenever the bootloader flash data is updated, I first erase the entire sector. Then I program my data.

I am noticing after 1-3 flash writes the sector containing the bootloader flash data corrupts and the memory goes to 0. All of the HAL functions HAL_FLASH_Unlock, HAL_FLASH_Program, HAL_FLASH_Lock return HAL_OK.

The general sequence by which I update the bootloader is the following

1) taskENTER_CRITICAL

2) Erase bootloader

3) taskEXIT_CRITICAL

4) taskENTER_CRITICAL

5) HAL_FLASH_Unlock

6) HAL_FLASH__Program...

7) HAL_FLASH_Lock

😎 taskEXIT_CRITICAL

9) Verify data by reading

Note that I am using FreeRTOS in the bootloader. When ever I am writing to flash I disable interrupts using taskENTER_CRITICAL and taskEXIT_CRITICAL.

a) What could be the reason why the sector containing the bootloader flash data corrupts? (My guess is that flash is locked and unlocked too many times?)

b) How can I debug this?

c) The micro needs to store data even after power off. As such Backup RTC/RAM is not possible. Will write data to flash every ~10 days.

[AAgar.2]

Ok will do.

Looking under Cortex _M7->CPU ICache/DCache in CubeMX as you have instructed does show that this is disabled. As such I don't think the DCache is an issue.

I am unsure why this is happening but I have changed my code to do minimal flash operations to the point where this situation in the answer is not occurring. I'm having other issues with flash but not this.

Appreciate your support.

[Piranha]

OK. By the way, reconsider whether you really need RTOS in a bootloader. Bootloader should be as simple and robust as possible and bullet-proof. Eliminating multi-threading can significantly reduce amount of potential multi-threading related bugs.

[AAgar.2]

Its mainly to reuse code that I have running on a multi-threaded system. I am minimizing the RTOS significantly to only use the minimal port.

I am carefully entering/exiting in critical sections.

RTOS is never initialized when a jump happens.

My only concern is making the initial ram state consistent but ill deal with that a little later.