Stepping ends up in an ISR

[celephicus]

Hello,

Working on a Mega328P with loys of interrupts. When I set a breakpoint in the mainline code, after a few steps with gdb "next" command I end up in an ISR. I can't seem to escape from these beyond setting another breakpoint in my code and using "continue". Any advice? Atmel Studio could stop the device clocks when it was halted, which reduced the occurrence. Avarice has a command line option that avoided next or step entering ISR's at all.

tom AT redgumandrust com au

[navnavnav]

Hi @celephicus

Bloom doesn't currently provide any configuration option for stop timers, but I assumed the EDBG tools would stop the timers by default. But I have not confirmed this, so it's possible that the timers are still running whilst the target is stopped.

I have prepared an unofficial build for you, v1.0.3, which accepts the stopTimers target config param in your bloom.yaml:

target:
  # ...
  stopTimers: true

DEB: https://github.com/bloombloombloom/Bloom/releases/download/v1.0.0/Bloom-1.0.3-Linux-x86_64-unofficial.deb
RPM: https://github.com/bloombloombloom/Bloom/releases/download/v1.0.0/Bloom-1.0.3-Linux-x86_64-unofficial.rpm
PKGBUILD: https://github.com/bloombloombloom/Bloom/releases/download/v1.0.0/Bloom-1.0.3-Linux-x86_64-unofficial.pkg.tar.gz

That build will configure the EDBG tool to stop the timers when the target is stopped, if stopTimers is set to true.
I haven't spent much time testing it, so please let me know if works. I may include the change in the upcoming v2.0.0 release.

Avarice has a command line option that avoided next or step entering ISR's at all.

Not sure how it would do that, but my guess is that it just disables all interrupts via the status register, before performing the step. This is something I could implement in Bloom, but not in the upcoming release.

[navnavnav]

Thinking about this some more:

In Bloom v2.0.0, I have introduced four GDB monitor commands, for accessing registers on the target. One of them, wrb, allows for writing to individual bit fields on the target. You could use this to disable global interrupts, by updating the "I" flag in the status register:

(gdb) mon wrb cpu sreg i 0b0

And to enable:

(gdb) mon wrb cpu sreg i 0b1

"cpu" is the peripheral key (in which the status register resides), "sreg" is the register key of the status register, "i" is the bit field key, and "0bX" is the value we wish to write to the bit field.

So in v2.0.0, you will have the ability to disable global interrupts whenever you want, via GDB. You can put this into a user defined GDB command, to create a "step without interrupts" command. Something like this:

define next-ni
    mon wrb cpu sreg i 0b0
    next
    mon wrb cpu sreg i 0b1
end

Now you can invoke that "next-ni" command, to perform a next step, with interrupts disabled:

(gdb) next-ni

For more on user-defined GDB commands: https://sourceware.org/gdb/current/onlinedocs/gdb.html/Define.html

But you'll have to wait for v2.0.0 to try this out. I'm looking to push that release in the next 3-4 weeks.

Here's the draft documentation for the wrb GDB monitor command, in case any of the above is unclear:

And here's the list bit fields (including their keys), from the new target details page (which will be going live with the v2.0.0 release):

[navnavnav]

Bloom v2.0.0 has just been released. See Accessing target registers via GDB for more on those new GDB monitor commands I mentioned in my previous comment.

[felias-fogg]

Hi navnavnav,

I addressed this issue in a blog post. It seems to be a GDB bug or a feature (?). I addressed it in my debugWIRE hardware debugger by executing each single instruction step (that is what GDB will tell the GDB server) in the internal execution register (or using simulation for 2-word instructions). This makes next-step instructions independent of interrupts. They either do not happen (when single-stepping) or happen in the background (when stepping over a function call). As far as I can tell, you can issue such offline execution also in the EGDB protocol.

Note that all this orthogonal to whether timers (and PMW) are active or not while you are in stopped state.

[navnavnav]

Thanks for this, @felias-fogg.

Very interesting. I hadn't considered that approach as a potential solution. This will not be considered for the upcoming release, but I may include it in the subsequent release.