The debugger uses Serial, so you can only add breakpoints where you can normally add a Serial.print statement.

I don't think you can do that interrupts and even if it worked I think it would throw the timings out.

I think this is why is is recommended that an interrupt write to a global variable and that the normal loop detects the change of value and responds accordingly. I might be wrong but even a digitalWrite() is a lot in an inerrupt notification handler, this isn't a strong area for me. Sorry

Hi Bryan,

I haven't gotten breakpoints to work in ISR's either. I might be wrong, but you will probably need a hardware debugger to do this. I know it can be done in the PIC world with an ICD 3 or the likes. The issue is Vm inserts serial writes and delays behind the scenes which scallops the ISR's.

I think what Tim was eluding to is similar to the snippet of code below:

// avr-libc library includes
#include <avr/io.h>
#include <avr/interrupt.h>

#define LEDPIN 13
volatile boolean flash = false;
void setup()
{
    pinMode(LEDPIN, OUTPUT);

    // initialize Timer1
    cli();          // disable global interrupts
    TCCR1A = 0;     // set entire TCCR1A register to 0
    TCCR1B = 0;     // same for TCCR1B

    // set compare match register to desired timer count:
    OCR1A = 15624;
    // turn on CTC mode:
    TCCR1B |= (1 << WGM12);
    // Set CS10 and CS12 bits for 1024 prescaler:
    TCCR1B |= (1 << CS10);
    TCCR1B |= (1 << CS12);
    // enable timer compare interrupt:
    TIMSK1 |= (1 << OCIE1A);
    // enable global interrupts:
    sei();
}

void loop()
{
    // do some crazy stuff while my LED keeps blinking
    while(1)
    {
      digitalWrite(LEDPIN, flash);
    
    }
}

ISR(TIMER1_COMPA_vect)
{
    flash = !flash;
}  

Then you can set your BP on the while(1) and inspect your variables.
The best way to handle the ISR routines is to set a volatile flag (flash) and get out.
Then poll for the change in your code.

Hope this helps,

Dennis

I used to use Proteus as a debugger and it worked fine with Interrupts, but I suspect Proteus is almost a  a semi-hardware type interface that runs in software..

I agree by getting in and out of a ISR as fast as possible, although I do see a pitfall with assigning the pin output to a variable as in the example., What if in the main loop that particular piece of code is not called right away because it's doing something else, like LCD refreshs, user inputs etc.  Guess it all depends on the design and how critical the interrupt is.