CFGBSY bit of FLASH SR register is SR is set it is not reset again in stm32g0b1cet6 controller #stm32g0 series

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

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?

[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.

[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.

[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