Bug when using FP code (repros in all SDK exampless here): addresses are offset by 32 bytes

[robcazzaro]

I had an issue where in the debugger, all local variables in a function were offset by 32 bytes. It didn't happen on all functions, and not on global variables. And it happens only with a specific program, cannot reproduce it with simpler code. Unfortunately the app I can reproduce with contains company-specific IP, so cannot provide the steps to reproduce it. I'm writing for a nRF52832, in case it makes a difference (I don't think it does)

In examining the JLINK_MONITOR files, I noticed that the code has a special case for the extended stack frame, and I tried changing the offset. It turns out that my problem can be fixed with a single change in JLINK_MONITOR_ISR_SES.s:

#define _NUM_BYTES_BASIC_STACKFRAME 32 #define _NUM_BYTES_EXTENDED_STACKFRAME 104 // was 72

I double checked and in all my code only one function seems to use the extended stack frame.

When reading the ARM documentation (https://developer.arm.com/docs/dui0553/a/the-cortex-m4-processor/exception-model/exception-entry-and-return) it's clear that the extended frame is 18 32-bit words longer than the basic one, so it's 18*4=72 bytes longer. And the total offset for extended is 104 instead of the basic 32

I'm really out of my league here, but I think that the following code

    LSRS     R1,LR,#+5 
    ITE      CS
    ADDCS    R0,R0,#+_NUM_BYTES_BASIC_STACKFRAME
    ADDCC    R0,R0,#+_NUM_BYTES_EXTENDED_STACKFRAME

Adds either the basic offset or the extended offset, depending on the carry. But the extended stack is 72 bytes more than the basic stack, so needs to add basic+extended (or add _NUM_BYTES_BASIC_STACKFRAME in any case and then add 72 if CS is true). As it is, the code is not working properly for the functions with an extended stack frame

The simplest fix is to change 72 to 104. And I think it would apply to all M4-based nRF5 cores. Incidentally the code is the same in the Keil version of JLINK_MONITOR_ISR_ARM.s, so the fix applies to both

EDIT: Adding link to the same issue in the Segger forums https://forum.segger.com/index.php/Thread/7292-Potential-bug-in-Monitor-Mode-Debug-example/

I think that these issues are related https://forum.segger.com/index.php/Thread/5904-SOLVED-Jlink-Monitor-Mode-nRF52-SDK-debug-issues/ (by making the variable static instead of local, the local stack is not used) https://devzone.nordicsemi.com/f/nordic-q-a/42248/monitor-mode-nrf52-sdk-debug-issues (FPU code triggers usage of the extended stack)