Why didn't I observe the issue in `xPortPendSVHandler` while doing step by step execution?

Kernel
1

Hey there !
I’m actually writing a port of the SMP Configuration for the Cortex-M7 (yes, I know… I’ll probably do a dedicated topic when I end, if the company allows me to share the results of my internship. :smiley: )
To do so, I had to modify xPortPendSVHandler, in port.c, among other things, to add a call to the functions to identify the current core, and the use of pxCurrentTCBs instead of pxCurrentTCB. I took time to do things properly : the modification I did are in preprocessor conditions. Thus, when compiling for single core, everything is working !
I had an unexpected behavior : Only when compiling with the SMP configuration, the loop sending chars to the UART went crazy ! and at a point, started to send bytes in memory that are not supposed to. The reason : the r4 register (the one handling the loop counter) take the value 0xFFFFFFFF instead of being decremented, always at the same moment !!
To debug, I put a breakpoint in Segger Ozone at the beginning of the loop : the execution breaks at each loop turn. I observed two things.

  1. When I clicked on run to do a loop turn, the issue occurred systematically when clicking for the twelfth time.
  2. When I stopped at the eleventh to do step-by-step execution : Everything works great, for the 12th, the 13th loop turn… but it occurs when I click on run anew again for the 14th.

I’m lucky I got an intuition and tested it out : The issue occurs in xPortPendSVHandler, where I modify the r4 register !!! So now it’s solved with a proper use of this register. (So now, there is new issues to debug. :tada: )

Here is my question : Why did I not observed the problem when I did step execution ? is it because the PendSV IT, or maybe the SysTick IT, is not triggered when I do step by step execution ? Is it because Segger Ozone disable IT when it breaks the execution ? Or maybe it’s a behavior related by the M7 (and other cortex-M) archi ?
While I resolved my issue, I need to understand the observations I did, to think to it sooner the next time. Unfortunately, I can’t find any sources about this. :frowning:

Thanks !! :heart:

2

That is right. In your case, R4 gets corrupted only when PendSV handler executes. So, most likely, when you are stepping through the PendSV handler does not execute and therefore, the code seems to work. It is not uncommon and I have seen such behavior before.

Most likely a debugger or timing behavior but I am not sure about it.

Great that you worked it out! Thank you for reporting it here.

1 Like