When setting read protection Level is an hard fault generated?

[DJaco.19]

Hi experts,

I am using an STM32F429. I set in the option bytes the read protection level to 1 (with the process specified in the reference manual) and it seems that after writing of the new data into the option bytes finished the MCU automatically issues an bus fault (this occurs always). In the documentation it says that a bus fault may occur if, e.g., a debuger is connected and tries to access the protected areas, but this also happens when no debugger is attached. After resetting the MCU manually everything works fine again.

Is this the normal behaviour? I coud not find anything in the datasheets/manuals so far. The only hint in this direction is the comment in the documentation of the F4Cube-HAL libs regarding option byte programming, where it states that a reset will occur and there is no code in the lib-functions to trigger this reset. (I am not using the F4Cube-HAL, i have my own).

Any insights are welcome.

Additions:

It seems that writing a new Value thats also a Level 1 and writing the option bytes with the same values does not trigger the bus fault. But when switching from readprotection Level 0 -> 1 it triggers a bus fault and i don't see anithing inside my code that my cause this.

[DJaco.19 · Accepted solution]

Ok, solution found.

I did not had any debug session open, but the debugger was still connected to the chip and I had a session open before (thus some where it was most probably marked as debug). This was enough to trigger the bus fault, as due to AN4701 in debug state the flash is not readable and therefore the fetch of the next instruction was enough to trigger the bus fault, after the option bytes were written and the read protection effective.

[After Forever]

Good, thanks for sharing your solution, but I never knew one can Like his/her own comment! 🙂