Skip to main content
Visitor II
January 17, 2024
Question

STM32F429IGT7 has a very serious problem

  • January 17, 2024
  • 2 replies
  • 982 views

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;

    This topic has been closed for replies.

    2 replies

    Graduate II
    January 17, 2024

    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.

    SSssAuthor
    Visitor II
    January 17, 2024

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

    #define OPTCR_BYTE0_ADDRESS ((uint32_t)0x40023C14)

    Graduate II
    January 17, 2024

    Are you writing OPTCR OPTSTRT correctly?