STM32F429IGT7 has a very serious problem

[SSss]

I found a very serious problem while using BOR, which caused my program to be erased innocently.

At least 0x0800 0000-0x081f ffff is like this,This is the result obtained by jlink

I need to use the BOR function when I power on, originally this function is to prevent me from abnormal power failure during the power on

The result is that an abnormal power failure of the program during the configuration of BOR will cause all the contents of my internal flash to be erased

This feature did solve another problem I had, but this new one is much more serious.

This is the conclusion that our team has come to after many tests, and we suspect that this will be the case when configuring other option words.

I hope you will respond to this matter

thanks

The following is my BOR configuration:
if((FLASH->OPTCR & FLASH_OPTCR_OPTLOCK) != RESET)
{
/* Authorizes the Option Byte register programming */
FLASH->OPTKEYR = FLASH_OPT_KEY1;
FLASH->OPTKEYR = FLASH_OPT_KEY2;
}

/* Set the BOR Level */
*(__IO uint8_t *)OPTCR_BYTE0_ADDRESS &= (~FLASH_OPTCR_BOR_LEV);
*(__IO uint8_t *)OPTCR_BYTE0_ADDRESS |= 0x0;

/* Set the OPTSTRT bit in OPTCR register */
*(__IO uint8_t *)OPTCR_BYTE0_ADDRESS |= FLASH_OPTCR_OPTSTRT;

FLASH->OPTCR |= FLASH_OPTCR_OPTLOCK;

[Tesla DeLorean]

Pretty sure this RMW action against the option bytes directly in this fashion in not supported.

Check example code as to how options are modified. Use library code.

[Tesla DeLorean]

Are you writing OPTCR OPTSTRT correctly? 

[SSss]

I followed the instructions, and the function still works if the power does not drop

#define OPTCR_BYTE0_ADDRESS ((uint32_t)0x40023C14)