strange debugging behaviour

[Anon767]

Hi,

Im using the System Workbench and a strange behaviour occured to me.

When a certain halting point is reached, Im not able to step to the next one. Pressing Resume brings me back to the very same halting point, stepping over aswell. And stepping into always brings me to the Ethernet Interrupt Handler.

Is this by design or a bug?

[Tesla DeLorean · Accepted solution]

On what part?

The CM0 and CM7 have some issues with single-step.

Is code running out of QSPI?

Do you have Ethernet in your system, or is this more of a Default_Handler thing?

Debugging typically doesn't stop the rest of the system running, if the Ethernet is getting interrupts faster than your response time, it can be the next thing to execute.

I'm not sure some of these things are bugs, but rather that you're at the edge of the universe, the debugger is the fractional use case for the core and transistors aren't wasted to make things perfect under all conditions.

Try code without optimization, this confuses the debugger less as it tries to resolve assembler to C source lines.

Use a disassembly view, step those, and review a static listing file.

Instrument your code to better understand dynamic behaviour and flow.

#MatrixGlitching #Milliways

[Tesla DeLorean]

An interrupt storm can occur if you don't service the cause(s), the tail-chaining will keep entering the IRQ Handler, and no foreground code will execute.

[Anon767]

hm thats quite cool, thanks you helped me a lot 🙂