STM32H7 Option bytes programming halts CPU

[NilocA]

The MCU halts for approximately 300ms after setting the OPTSTART bit in the FLASH_OPTCR register. In HAL_FLASH_OB_Launch() :

HAL_StatusTypeDef HAL_FLASH_OB_Launch(void)
{
 HAL_StatusTypeDef status;
 
 /* Wait for CRC computation to be completed */
 if (FLASH_CRC_WaitForLastOperation((uint32_t)FLASH_TIMEOUT_VALUE, FLASH_BANK_1) != HAL_OK)
 {
 status = HAL_ERROR;
 }
#if defined (DUAL_BANK)
 else if (FLASH_CRC_WaitForLastOperation((uint32_t)FLASH_TIMEOUT_VALUE, FLASH_BANK_2) != HAL_OK)
 {
 status = HAL_ERROR;
 }
#endif /* DUAL_BANK */
 else
 {
 status = HAL_OK;
 }
 
 if (status == HAL_OK)
 {
 /* Set OPTSTRT Bit */
 SET_BIT(FLASH->OPTCR, FLASH_OPTCR_OPTSTART);
 
 /* Wait for OB change operation to be completed */
 status = FLASH_OB_WaitForLastOperation((uint32_t)FLASH_TIMEOUT_VALUE);
 }
 
 return status;
}

I tested this on the STM32H743I-EVAL2 eval board and I didn't find any information in the ST documentation.

When OPTSTART bit is set, the embedded Flash memory launches the option byte modification in its non-volatile memory and updates the option byte registers with _CUR extension.

That can explain a little delay but 300ms seems way too long.

Thanks for your help

[Andreas Bolsch]

Datasheet says 1 to 4 seconds sector erase time for 128kByte sector. The option bytes sector is certainly much smaller, but erase time in the order of several 100ms seems plausible.

​

Note that the option bytes flash cells are not EEPROM cells, i.e. the whole block is erased, then reprogrammed. This even suggests that option byte programming is a rather delicate operation. Any power glitch in the meantime and ...

[FBL]

Hello @NilocA​,

The CPU is stalled during the write to Flash (erase/programming)