Ignore Timer Interrupts During Debugging?

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,
(1) Looked at the forum for "debug timer interrupts", but couldn't see a match for this 'bug'.
(2) Not sure if this should be here or GCC forum;
but here goes:

How do I get the debugger to ignore timer interrupts?

I'm happily stepping through code, and every 10 or 20 lines, or if there's a serial Tx, bam!, the debugger jumps to the timer ISR.

That's no too bad, since the ISR is one line:

timer_msec_free_running_counter++;

The problem is that after the ISR exits, you can be down into some low level routine, typically a RS232 or I2C routine, which might be 5 or 7 levels below the code that I was debugging.

Returning from this always problematic, since comms typically involves plenty of loops, e.g., to transmit buffers, etc.

Other IDEs, e.g., RowleyCrossStudio(for ARM + GCC) do not have this 'problem'.

How can I get the debugger not to step into the ISR?

Thanks, "That's just another burr in my socks" Alf

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
The problem is that after the ISR exits, you can be down into some low level routine, typically a RS232 or I2C routine, which might be 5 or 7 levels below the code that I was debugging.

But wouldn't the code return to exactly where it was interrupted? How could it be otherwise since the main code is suspended when the interrupt happens?

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, Koshchi,
Because it's not the "main" code that is suspended. No, what I see is this: as part of the main code I'm debugging, it might call:

1:DsdMemRecordGet(), which calls
  2:DsdMemRecordBinarySearch()
    3:DsdMemRecordGetViaIndexSkipEmpty()
      4:DsdMemRecordGetViaIndex()
        5:HwChipTransmitCommandAndAddress() << some SPI comms
          6:HwChipTransmitSpi()             << more SPI comms
            7:HwChipSelect()

You get the idea.
I might be debugging 1:DsdMemRecordGet(), and ask it to step over 2:DsdMemRecordBinarySearch().

While 2:DsdMemRecordBinarySearch() is executing, the timer ISR occurs, which the debugger pauses at. After the ISR terminates, the code returns perhaps to 6:HwChipTransmitSpi(), not to the next instruction after 2:DsdMemRecordBinarySearch().

Alf

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Manually turn off the offending interrupt bit while debugging, At least that's how I do it :)
I'm ASS_U_MEing you are using a JTAG ice or a Dragon for debugging.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JS,
That's good & simple, except annoying: needs to be done with every restart/reload.
Besides, why can other IDEs do it, and not this? (the usual answer to questions of this type, is another question: "who's paying for it?")
Also, yes, JTAGICE(mII).
Alf

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, in that situation I don't see any reason for the debugger to stop in the ISR. I would call that a bug in the debugger.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I don't see any reason for the debugger to stop in the ISR.
Well it doesn't stop there as such from what I understand, but if you are single stepping through some code and an interrupt happens then the next step will be into the ISR as in real life.

If it is only the timers bothering you, perhaps you can go into the Debug>JTAG options> and then into the debug tab, perhaps you haven't unchecked the "run timers in stopped mode" box. Don't know if this will be the solution for you.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Well it doesn't stop there as such from what I understand, but if you are single stepping through some code and an interrupt happens then the next step will be into the ISR as in real life.

But he stated that he was stepping over a function, so the next stopping point for the debugger should be just after that function, regardless of what other functions are called during that time (and no matter how those functions are called).

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just out of interest, what is this set to?...

But I'd also switch to the interleaved C/Asm view where [step] will step one opcode, not one line of C and then see what happens as it steps into and back out of the ISR. I'd be astonished if the RETIs aren't really getting back to the starting point!

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I'd be astonished if the RETIs aren't really getting back to the starting point!

But he is talking about the case where you step over an rcall rather than into it, and having the interrupt happen during the rcall. The reti will return him to the point of the actual interrupt rather than to just after the rcall. The latter is the behavior he desires.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson & others,
"Run timers in stopped mode" is unticked (unchecked).

Also, thanks to Koshchi for emphasising that "The reti will return him to the point of the actual interrupt rather than to just after the rcall. The latter is the behavior he desires."

Alf Lacis
http://alfredo4570.customer.netspace.net.au