[SOLVED] RP2040 + J-Link 4.95d Beta - Cortex-M0+ not responding to PendSV

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

  • [SOLVED] RP2040 + J-Link 4.95d Beta - Cortex-M0+ not responding to PendSV

    I'm using the J-Link 4.95d Beta software to debug an RP2040.

    As per this StackOverflow question, I've found that single-stepping an instruction that writes to the PENDSVSET flag causes the PendSV to register as pending, but to never enter the PendSV handler.

    As can be seen, PENDSVSET reads as set and VECTPENDING reads as 0xe - indefinitely, regardless of stepping and/or free-running subsequent instructions (at least until another exception occurs).

    [img]https://i.stack.imgur.com/i4P6H.png[/img]


    I wonder if this may be due to the J-Link not performing the step operation exactly as required (e.g. manipulating DHCSR.C_MASKINTS incorrectly) - or if it's simply the way the Cortex-M0+ works in this situation?

    Cheers
    Jeremy

    PS: Many thanks for Beta-releasing the RP2040 support so promptly!

  • Replying to my own post here. It turns out that my original observations were a bit sloppy - this behaviour is simply due to interrupts (including PendSV) being disabled during all step operations. As soon as any kind of run is invoked (including run to the very next instruction) the PendSV is immediately serviced.

  • You also need to distinguish C-level stepping and assembly single stepping.
    While a single step on assembler level have interrupts disabled, a C-level step (step over, step-into, ...) has interrupts enabled.
    For assembly step-over operations, interrupts are also enabled.

    We will consider this thread as closed.

  • SEGGER - Alex wrote:

    You also need to distinguish C-level stepping and assembly single stepping.
    While a single step on assembler level have interrupts disabled, a C-level step (step over, step-into, ...) has interrupts enabled.
    For assembly step-over operations, interrupts are also enabled.

    Of course there's another factor involved, which is how the debugger (in my case VSCode cortex-debug & GDB) translates source-level stepping into J-Link commands.

    From what I've observed, it appears that when source-level stepping a C statement that compiles to a single instruction, this particular debugger issues an assembler-level single step (i.e. with interrupts disabled), whereas a statement that compiles to multiple instructions is stepped with interrupts enabled. I can understand why, but it does lead to some head-scratching.

    Thanks for the clarification, happy to close.