RDERR flag set before any PCROPed code involvement [STM32F429]

[Florencia]

Hi all, first time working with stm32.
So far I've managed to make things work, I've even workarround this issue (*), but I can't seem to understand why this is happening in the first place.

STM32F429, STMCubeIDE, ST-LINK/V2

This is my situation:
Execution of code starts at Sector 1.

Sector 1 & 2: My_Bootloader (to the effects of this post, not PCROPed)
Sector 3: My_SecureSegment (PCROPed, code compiled with -mpure-code option, memory section attribute (x): executable code (**) )
Sector 4 and on: My_Application (not PCROPed)


I start the debugger, it gets halted at Reset_Handler (as expected).

Reset_Handler: 
  nop
  nop
  nop
  movw	r0, #:lower16:_estack
  movt	r0, #:upper16:_estack
  mov	sp, r0

(added the nops just to demonstrate the kind on instruction that's being executed)

No error flag set (FLASH_SR = 0)

Step Into (instruction stepping mode active), one nop executes

RDERR flag gets set.

From Reference Manual [RM0090 - 3.9.6 Flash status register (FLASH_SR)]:

So, who is attempting to access the PCROPed sector? Why is this flag set? Am I doing something evidentely wrong?

More info in case you find it useful:
a) When no sector is PCROPed, no flag gets set.
b) When a sector that does not contain any code is PCROPed, no flag gets set.
No surprises there but just in case...


Any input would be appreciated.
Thank you all, Florencia

(*) Found out about this flag being set because HAL code was checking it and wouldn't allow me to erase and reprogram My_Application (not PCROPed sectors). I decided to simply ignore the fact that it was set and had no trouble updating FW.
(**) Not sure if this linker attribute is necessary. Wouldn't mind any advice on this.

[Florencia · Accepted solution]

So. It looks like I was doing something evidentely wrong. It's a pretty basic mistake actually.
It's the debugger who is trying to load symbols from the PCROPed sector.
In fact, when I only load symbols from the not PCROPed sectors, no flag is set by the debugger.

I'm gonna close this topic now and go back to my original problem which may or may not be caused by this flag.

Florencia.