Stepping through code interrupted

Hi everybody,

I'm currently evaluating Arm Development Studio as a replacement for uVision from Keil MDK.

I'm using the most recent version with an STM32H7, currently debugging the M7 core with an STLINK V2 - altough the problem persists with a J-LINK.

Currently, I'm struggling to properly step through code. As I have several periodic interrupts, I'm always ending up in an interrupt.

While this makes sense - interrupts occur at several kHz - this behavior is very different from how debugging worked in uVision where, while stepping through code, interrupts seem to be disabled.

I had a look through the commands listed here: https://developer.arm.com/documentation/101471/2000/Arm-Debugger-commands?lang=en but could not identify a command to disable interrupts while stepping through the code.

Is there any way/option to replicate how uVision stepped through code?

Thanks in advance, any help is highly appreciated!

Parents
  • Hi Sven

    Thanks for trying out Arm Development Studio!

    You are right that the behaviour of Arm DS Debugger should be similar to Keil MDK uVision in this respect.

    When single-stepping through code, Arm DS Debugger usually sets a breakpoint on the "next instruction" and then runs to it, so you shouldn't end up in an interrupt handler.  It uses various heuristics to determine what the "next instruction" actually is.  

    Please can you confirm that you are single-stepping at source-level ('step' or 'steps') rather than instruction-level ('stepi').  Does the same thing happen when single-stepping at instruction-level?

    Please can you also confirm that you have not accidentally enabled trapping of exceptions - see the Manage Signals button in the Breakpoints view.

    Hope this help

    Stephen

Reply
  • Hi Sven

    Thanks for trying out Arm Development Studio!

    You are right that the behaviour of Arm DS Debugger should be similar to Keil MDK uVision in this respect.

    When single-stepping through code, Arm DS Debugger usually sets a breakpoint on the "next instruction" and then runs to it, so you shouldn't end up in an interrupt handler.  It uses various heuristics to determine what the "next instruction" actually is.  

    Please can you confirm that you are single-stepping at source-level ('step' or 'steps') rather than instruction-level ('stepi').  Does the same thing happen when single-stepping at instruction-level?

    Please can you also confirm that you have not accidentally enabled trapping of exceptions - see the Manage Signals button in the Breakpoints view.

    Hope this help

    Stephen

Children
More questions in this forum
There are no posts to show. This could be because there are no posts in this forum or due to a filter.