Bug in Monitor Mode Debug example when using FP enabled code: variable addresses offset by 32 bytes

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Bug in Monitor Mode Debug example when using FP enabled code: variable addresses offset by 32 bytes

      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)

      The post was edited 1 time, last by robca ().

    • I looked into this a bit more, and I have solid repro steps for the nRF52832 (PCA10040), using the example referred here github.com/NordicPlayground/j-…a10040/s132/ses/README.md

      I reproduced both using SDK14.2 and SDK16 (so I assume it reproes even for SDK15)

      Set up the project as per instructions (use the ble_blink example, copy the MMD files over), ensuring to select the debug build to disable code optimization. Verify that MMD works as expected.

      Then add the following function to main.c

      Source Code

      1. static void to_debug()
      2. {
      3. float foo1 = 3.14;
      4. float foo2 = 2.71;
      5. char array[] = "01234567";
      6. int foo = foo1 * foo2;
      7. NRF_LOG_INFO("Foo = %d", foo);
      8. NRF_LOG_INFO("&array = 0x%08x", &array);
      9. }
      Display All
      Call to_debug() from the main loop

      Source Code

      1. // Enter main loop.
      2. for (;;)
      3. {
      4. idle_state_handle();
      5. to_debug();
      6. }
      If you have logs enabled, make a note of the array address printed by NRF_LOG (0x2000FFD8 in my case), then break into the to_debug() function and add array to the watch window. You will see that the content is not "01234567". Add also &array to the watch window, notice that the address in that case is 0x20 less than actual (0x2000FFB8 in my case). If you look at the memory location starting from 0x2000FFB8, you will see the 01234567 32 bytes later than reported by the debugger.

      Now edit JLINK_MONITOR_ISR_SES.s, changing #define _NUM_BYTES_EXTENDED_STACKFRAME from 72 to 104.

      Source Code

      1. #define _NUM_BYTES_EXTENDED_STACKFRAME 104
      Recompile. Now you can debug to_debug() without problems, and the watched variables appear correctly
    • Hello,

      Thank you for your inquiry.
      You are correct. The stackoffset was not calculated correctly for FPU applications. This will be fixed with the next J-Link software release.
      Our samples will also be updated accordingly.

      Sorry for any inconveniences caused.

      Best regards,
      Nino
      Please read the forum rules before posting: Forum Rules

      Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/

      Or you can contact us via e-mail.