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 · Accepted solution]

Hello @NilocA​,

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