I think I found a potential bug in segger.com/downloads/pub/Gener…odeSystickExample_SES.zip, which I also reported here github.com/NordicPlayground/j-…g-mode-debugging/issues/5
To summarize: when debugging a function on a M4 core (nRF52832) that uses the extended stack frame, the SES debugger shows all variables with a 32 bytes offset, making it very hard to debug that function (must use memory monitor instead of the watch window and use +32 bytes addresses compared to the ones reported by Segger)
In examining JLINK_MONITOR_ISR_SES.s, the code is not properly adding the extended frame offset
#define _NUM_BYTES_BASIC_STACKFRAME 32
#define _NUM_BYTES_EXTENDED_STACKFRAME 72
LSRS R1,LR,#+5 // LR[4] -> Carry == 0 => extended stack frame has been allocated. See ARM DDI0403D, B1.5.7 Stack alignment on exception entry
ITE CS
ADDCS R0,R0,#+_NUM_BYTES_BASIC_STACKFRAME
ADDCC R0,R0,#+_NUM_BYTES_EXTENDED_STACKFRAME
It looks as if the code is adding 32 or 72, depending on the type of stack frame (basic vs extended). But the difference between the basic and extended code, based on this developer.arm.com/docs/dui0553…xception-entry-and-return is 18 32-bit works, i.e. 72 bytes longer than the basic one. So the code must either first add 32 then another 72 if the stack is extended, or the extended stack offset must be changed to 104 from 72 (i.e. 32+72)
After changing _NUM_BYTES_EXTENDED_STACKFRAME to 104, everything works as expected while debugging. And it should be a very safe change
Incidentally, MMD is incredibly useful and a life changer on nRF5 devices with an active communication stack.
EDIT: I think that these issues are related
[SOLVED] Jlink Monitor Mode + nRF52 SDK debug issues (by making the variable static instead of local, the local stack is not used)
devzone.nordicsemi.com/f/nordi…de-nrf52-sdk-debug-issues (FPU code triggers usage of the extended stack)
To summarize: when debugging a function on a M4 core (nRF52832) that uses the extended stack frame, the SES debugger shows all variables with a 32 bytes offset, making it very hard to debug that function (must use memory monitor instead of the watch window and use +32 bytes addresses compared to the ones reported by Segger)
In examining JLINK_MONITOR_ISR_SES.s, the code is not properly adding the extended frame offset
#define _NUM_BYTES_BASIC_STACKFRAME 32
#define _NUM_BYTES_EXTENDED_STACKFRAME 72
LSRS R1,LR,#+5 // LR[4] -> Carry == 0 => extended stack frame has been allocated. See ARM DDI0403D, B1.5.7 Stack alignment on exception entry
ITE CS
ADDCS R0,R0,#+_NUM_BYTES_BASIC_STACKFRAME
ADDCC R0,R0,#+_NUM_BYTES_EXTENDED_STACKFRAME
It looks as if the code is adding 32 or 72, depending on the type of stack frame (basic vs extended). But the difference between the basic and extended code, based on this developer.arm.com/docs/dui0553…xception-entry-and-return is 18 32-bit works, i.e. 72 bytes longer than the basic one. So the code must either first add 32 then another 72 if the stack is extended, or the extended stack offset must be changed to 104 from 72 (i.e. 32+72)
After changing _NUM_BYTES_EXTENDED_STACKFRAME to 104, everything works as expected while debugging. And it should be a very safe change
Incidentally, MMD is incredibly useful and a life changer on nRF5 devices with an active communication stack.
EDIT: I think that these issues are related
[SOLVED] Jlink Monitor Mode + nRF52 SDK debug issues (by making the variable static instead of local, the local stack is not used)
devzone.nordicsemi.com/f/nordi…de-nrf52-sdk-debug-issues (FPU code triggers usage of the extended stack)
The post was edited 1 time, last by robca ().