As for STM32H563 MCU, will it result in a system reset after executing the function HAL_FLASH_OB_Launch? From my experiment, before executing HAL_FLASH_OB_Launch, I can read data from MCU via I2C while all returned data become 0xFF(i.e. invalid data) after executing this function. It seems that the MCU is suspended or reset. When I tried to trace the code through Debugger Section in Keil, the code can run smoothly to subsequent routines.
Here is my code below.
void EnableWriteProtect(uint8_t image)
{
FLASH_OBProgramInitTypeDef OBInit = {0};
FLASH_OBProgramInitTypeDef sOBPrev = {0};
uint32_t WRPSector;
/* Unlock the User Flash area */
HAL_FLASH_Unlock();
HAL_FLASH_OB_Unlock();
/* Get the boot configuration status */
HAL_FLASHEx_OBGetConfig(&OBInit);
WRPSector = OBInit.WRPSector | BIT(0);
OBInit.Banks = FLASH_BANK_2;
OBInit.OptionType = OPTIONBYTE_WRP;
OBInit.WRPState = OB_WRPSTATE_ENABLE;
OBInit.WRPSector = WRPSector;
HAL_FLASHEx_OBProgram(&OBInit);
/* Launch Option bytes loading */
HAL_FLASH_OB_Launch();
/* Unlock the User Flash area */
HAL_FLASH_OB_Lock();
HAL_FLASH_Lock();
}
From my experiment, before executing HAL_FLASH_OB_Launch, I can read data from MCU via I2C while all returned data become 0xFF(i.e. invalid data) after executing this function. It seems that the MCU is suspended or reset. When I tried to trace the code through Debugger Section in Keil, the code can run smoothly to subsequent routines.
My expectation: I hope to implement write protection for specific MCU flash areas normally without resetting the MCU.
Reference manual section 7.4.3 says that you should reset the device after changing option bytes. This is mandatory under certain circumstances, strongly recommend otherwise.
This implies that the hardware doesn't do it for you, but probably somewhere in the HAL does follow what the documentation requires. You can search the HAL source to find where.