CFGBSY bit of FLASH SR register is SR is set it is not reset again in stm32g0b1cet6

[Dthum.1]

Hi everyone,

i am using the stm32g0b1cet6 controller. in which I am working with flash memory. I am using the FLASH_WaitForLastOperation function. In that function, one flash SR register's CFGBSY bit is not reset, and due to that all other flash write and erase processes it not working.

 

this issue is coming randomly.

 

before calling FLASH_WaitForLastOperation function I am clearing error flags as shown below

 

__HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_OPTVERR);

__HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_OPERR);

__HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_PROGERR);

__HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_WRPERR);

__HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_PGAERR);

 

__HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_SIZERR);

__HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_PGSERR);

__HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_MISERR);

__HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_FASTERR);

__HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_RDERR);

 

can someone please provide some input ASAP.

 

 

 

 

 

 

[Goutham R]

Facing the same issue with STM32G0B0RET6 microcontroller. Did you find any solution?

[Goutham R]

I have found a fix for CFGBSY not clearing issue.

Write some random data to an address inside the page that you are going to erase/write before unlocking the flash for writing.

 

 

 

 uint32_t PageError = 0;
 static FLASH_EraseInitTypeDef EraseInitStruct;

 EraseInitStruct.TypeErase = FLASH_TYPEERASE_PAGES;
 EraseInitStruct.Banks = BANK;
 EraseInitStruct.Page = PAGE;
 EraseInitStruct.NbPages = 1;

 FLASH->SR = FLASH_SR_CLEAR;

 for (uint16_t rte = 0; rte < 10; rte++)
 {
 if (__HAL_FLASH_GET_FLAG(FLASH_FLAG_CFGBSY) != 0x00U)
 {
 *(uint32_t*) (adr + 64) = 21323;
 __HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_ALL_ERRORS);
 }
 if (HAL_FLASH_Unlock () == HAL_OK)
 {
 FLASH_WaitForLastOperation (100);
 HAL_FLASHEx_Erase (&EraseInitStruct, &PageError);
 if (PageError == 0xFFFFFFFF)
 {
 break;
 }
 }
 }
 HAL_FLASH_Lock ();

 

 

 

 

Replace "BANK" & "PAGE" with your own variables.

 

[Dthum.1]

Hi Goutham,
Thanks for your input, I have tried with your suggestion, i found it is working as of now(tried 15 times)
Have you found the RCA for this issue? Why this CFGBSY is not clearing?

[Dthum.1]

Hi Goutham 
Update: Thanks for your valuable input, I have validated your fix on my setup by testing it 120 times, where I was facing the issue. it has worked each time and no issue I have found with this fix.

thanks, a lot.

here, what I have done is similar to your fix.

[rjack]

This is an issue I am experiencing as well on the STM32G0B1RE when interacting with FLASH the CFGBUSY bit will randomly not clear. It very much seems like an issue that should be present in the errata sheet.

 

Adding the work around posted by Goutham has worked so far.

[Tarun]

Hi,

MCU: STM32G0B0RE6

I was having similar issue with SBSFU and Application where watchdog refresh handler in application caused the problem. HAL Watchdog refresh handler in application not initialized in the application (No need to initialize in application for SBSFU projects) but refreshing watching with uninitialized handler caused to set CFGBSY flag in Flash->SR register then denied to flash write/erase operations.

I replaced HAL_IWDG_Refresh() with WRITE_REG(IWDG->KR, IWDG_KEY_RELOAD); 

fixed my problem.

 

Thanks,

Tarun

[waclawek.jan]

I came across what I believe is the same mechanism (this time on a 'L431) described here, which was caused by bug in user code (i.e. not Cube/HAL function), errorneously writing through a NULL pointer.

It means, that clearing FLASH_SR errors just hides a genuine bug somewhere else.

JW

 

[Goutham R]

I don't think the issue is in the user code, I have written a test code just to simulate this issue. The issue has been observed immediately after "SystemClock_Config (); " function call. And there is no other user code other than reading the CFGBZY flag and then writing data to the flash. The CFGBZY flag is already set even before writing anything to the flash after power cycle. 

[waclawek.jan]

> The issue has been observed immediately after "SystemClock_Config (); " function call.

Have *you* written that funcion? Do you have full control over what happens in that function? Are there any other functions called before calling that function? Are there any interrupts enabled and under your full control?

@Tarun above described a case, where Cube/HAL code was the culprit

As soon as you start using "libraries" such as Cube/HAL, those become part of your code, and, ultimately, your responsibility; so simply treat them as your code and in case of troubles, debug as appropriate.

Alternatively, write a test code without relying upon "libraries". Programming EEPROM/FLASH is relatively simple.

I don't say there are no hardware issues, just that past evidence indicates, that they are exceedingly rare, compared to software bugs.

JW

[Goutham R]

The "SystemClock_Config ()" is generated by CubeMX, I haven't enabled any interrupts in the testcode. After the code is generated by CubeMX I have added the code related to reading of the CFGBZY flag after SystemClock_Config function call, and the issue is even observed before doing any operation related to Flash except reading the state of CFGBZY flag. The issue is very random, sometimes the issue is observed continuously on every power cycle for more than 5 times and sometimes it is not observed. It's been a few months since I worked on it, don't have enough time to go back to it. My suspection is also on HAL, need to check whether the issue occurs without using HAL.

[Piranha]

When FLASH_SR error flags are set, the erase/programming doesn't work. It is quite logical, but it is not clearly documented in the reference manuals. But, of course, ST has no time for fixing such "unimportant" issues... That said, these flags do not appear without reason.

Last year I also reported this to SEGGER, because the J-Link was also failing to erase/program the flash, if the error flags were set.

https://www.segger.com/downloads/jlink/ReleaseNotes_JLink.html

Version V7.68b (2022-07-22)
DLL
ST STM32F7, STM32G0, STM32G4, STM32H7, STM32L0, STM32L1, STM32L4, STM32L5: Flash programming failed if any flash error bits were set before flash operation. Fixed.

[traxformania]

Is there any official explanation from ST about this topic?

This solution also fixed our problem.

STM32WB55RGV6

[James3DArts]

In my case this problem was caused by the HAL_I2C_Init() function, BUSY state popped out after this part

 

 

 hi2c->Instance->CR2 |= (I2C_CR2_AUTOEND | I2C_CR2_NACK);

 /*---------------------------- I2Cx OAR2 Configuration ---------------------*/
 /* Disable Own Address2 before set the Own Address2 configuration */
 hi2c->Instance->OAR2 &= ~I2C_DUALADDRESS_ENABLE;

 /* Configure I2Cx: Dual mode and Own Address2 */
 hi2c->Instance->OAR2 = (hi2c->Init.DualAddressMode | hi2c->Init.OwnAddress2 | \
 (hi2c->Init.OwnAddress2Masks << 8));

 /*---------------------------- I2Cx CR1 Configuration ----------------------*/
 /* Configure I2Cx: Generalcall and NoStretch mode */
 hi2c->Instance->CR1 = (hi2c->Init.GeneralCallMode | hi2c->Init.NoStretchMode);

 /* Enable the selected I2C peripheral */
 __HAL_I2C_ENABLE(hi2c);

 

[RusikOk]

STM32F745xx problem is present, not reflected in Errata