cancel
Showing results for 
Search instead for 
Did you mean: 

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

AOliv.6
Associate

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:


_legacyfs_online_stmicro_images_0693W00000bhkuJQAQ.png

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:


_legacyfs_online_stmicro_images_0693W00000bhkuTQAQ.png

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.

3 REPLIES 3
Uwe Bonnes
Principal III

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.

We are facing this same issue and code size is really big. It is not possible to identify by putting watchpoint like you suggested. Any other possible way to find the solution? Is this not the Bug ? Should it not generate the hard fault in such scenario?

The program in the opening post is invalid as it tries to write to flash with no special precautions or setup.

CFGBSY is readonly. It can't be set or cleared in software. Presumably it would be cleared when the rest of the flash word is attempted to be written (which will fail if flash is locked).

If you're still having issues open a new post with all relevant details. Fixing the bug is going to be the primary solution here.

If you feel a post has answered your question, please click "Accept as Solution".