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!
Hi SvenThanks 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 helpStephen
Hi Stephen,
Thanks for your quick response!
I'm using step:
wait step Execution stopped in Privileged Thread mode at breakpoint 4: 0x08036FA2 0x08036FA2 486,16 logger.Step(); wait step Execution stopped in Privileged Thread mode at breakpoint 4: 0x08036FA2 0x08036FA2 486,16 logger.Step(); wait step Execution stopped in Privileged Thread mode at breakpoint 4: 0x08036FA2 0x08036FA2 486,16 logger.Step(); disable 4 Breakpoint 4 disabled wait step Execution stopped in Handler mode at 0x08005DD0 In stm32h7xx_it.c 0x08005DD0 172,0 void DMA2_Stream4_IRQHandler(void) {
Please note, that I first have to disable the Breakpoint that stopped execution or else the step command will not advance at all... (the same is actually true for steps, next and continue)
While stepsi is not getting stuck in the breakpoint, it also does not advance the code but enters one of the periodic interrupts...
Execution stopped in Privileged Thread mode at breakpoint 4: 0x08036FA2 In app_m7.cpp 0x08036FA2 486,16 logger.Step(); continue Execution stopped in Privileged Thread mode at breakpoint 4: 0x08036FA2 0x08036FA2 486,16 logger.Step(); next Execution stopped in Privileged Thread mode at breakpoint 4: 0x08036FA2 0x08036FA2 486,16 logger.Step(); step Execution stopped in Privileged Thread mode at breakpoint 4: 0x08036FA2 0x08036FA2 486,16 logger.Step(); steps 10 Execution stopped in Privileged Thread mode at breakpoint 4: 0x08036FA2 0x08036FA2 486,16 logger.Step(); stepi Execution stopped in Handler mode at 0x0800EA98 In stm32h7xx_it.c 0x0800EA98 292,0 void HSEM1_IRQHandler(void) {
Nothing is selected in Manage Signals:
I suppose, that's how it is supposed to be.
Stepping through code without interrupts enabled works as intended...
Thanks in advance
Sven
P.S.: The usage of logger.Step() here is entirely arbitary, I've seen the same behavior for every instruction I used as a breakpoint.
Hi Sven
Thanks for your additional information. Sorry, but I still can't figure out what might be going wrong here.
I suggest you open a Support Case using the "Support > Open a Support Case" option at the top of this page, so that Arm support and engineering teams can properly investigate.
Stephen