Showing results for 
Search instead for 
Did you mean: 

Is possible to recover from unwanted FLASH->SR CFGBSY set bit?


TLDR: application tried to write to a FLASH address without accessing FLASH peripheral, so the Flash bit CFGBSY in the SR register got set and further accesses to FLASH CR register leads to a Bus Error (not documented). Of course, the main action is to correct the application behavior, but also tried to reset the bit (which from the documentation can only be reset by hardware) but didn't work.

Long story.

The application tried something as the follows.

static const uint32_t var = 0;

uint32_t * const p_var = (uint32_t * const)&var;

*p_var = 12;

the p_var contents assignment didn't generate a Bus Error, rather it set the CFGBSY bit in FLASH SR register.

From the documentation:


Interestingly the doc says nothing of the CR LOCK/OPTLOCK bits being inaccessible when CFGBSY.

The application at that point is not aware of the issue. Further a FLASH write is done and the CPU enters a Bus Error when trying to access the CR register to Lock the FLASH Memory.

From de Documentation:


The documentation says nothing about Bus Error in case the CFGBSY bit is set when accessing the CR register LOCK/OPTLOCK bits.

The solution:

  • setup the MPU to cover the .rodata section from memory to catch the offending code, and;
  • correct the application offending code, obviously it should not set a variable that is stored in FLASH without accessing the FLASH Peripheral;

But as much as the problem is already solved, there are some questions pending:

  • Why the FLASH Peripheral set the CFGBSY bit without the application change anything on the FLASH Peripheral directly?
  • This Bus Error is not documented or was not mapped by the documentation, is because of the CFGBSY bit? (I think that the Bus Error is because of the Read-Modify-Write operation on the register (and, by consequence on the other bits that are not accessible when the CFGBSY is set... even thought the inaccessible bits didn't change state);
  • Is there any corrective action to this behavior from the hardware (FLASH Peripheral) side? (CFGBSY set, so for an example an Bus Error Exception Handler can take and try continue to run the application after the corrective action);

Thank you in advance.

Uwe Bonnes
Principal II

Run in debug configuration, set, eventually sequential if lots of watchpoints are needed, watchpoints on all registers that could affect CFGBSY an run the program. I guess some bad access happens.