FLASH_SR CFGBSY flag is set after calling HAL_ADC_ConfigChannel() to configure internal temperature sensor on STM32G071

[CHoel.2]

Im initializing my ADC peripheral using the generated MX_ADC1_Init function. At the end of the function, the following snippet is executed:

sConfig.Channel = ADC_CHANNEL_TEMPSENSOR;
 
if (HAL_ADC_ConfigChannel(&hadc1, &sConfig) != HAL_OK)
{
Error_Handler();
}

after returning from this function, the FLASH_SR CFGBSY flag is set and i dont know why. Inside the function, we get to a point where we wait for

the temperature sensor to stabilize, using this snippet:

wait_loop_index = (((LL_ADC_DELAY_TEMPSENSOR_STAB_US / 10UL) * (SystemCoreClock / (100000UL * 2UL))) + 1UL);
 
while (wait_loop_index != 0UL)
{
	wait_loop_index--;
}

 until that, CFGBSY is still zero. When i step out of the function, CFGBSY is set. if i manualy reduce the wait_loop_index to 10, we do not get the issue!

I would not have realized it if i wasnt using the eeprom emulation middleware by ST, which tries to erase FLASH pages.

There we get stuck, because you can only erase -or write to- FLASH, if CFGBSY is zero.

Is this a known issue? If yes, how do i work around it?

[Amel NASRI]

Hi @CHoel.2​ ,

Please make sure that you are not de-initializing some peripheral (call of HAL_***_DeInit()) while it is not already instantiated?

If you enable the the USE_FULL_ASSERT feature, you can detect easily if there are non initialized parameters.

-Amel

[TDK]

Doing anything with the ADC should not be causing the flash to be busy. They are independent. And certainly reducing a delay doesn't seem like it would fix the issue. Likely something else is going on.

[waclawek.jan]

Which STM32? What exactly is in all FLASH registers? Do you use an RTOS? The "eeprom emulation middleware" does use any interrupts? What happens if you don't use that "eeprom emulation middleware"?

JW