Go Down

Topic: Interrupt still happening after detached. ( fix now available) (Read 3 times) previous topic - next topic

Loudhvx


(Believe it or not, some people actually program things other than Arduino boards and with compilers other than avr-gcc, and they like to keep things vendor-independent wherever it's practical.  Really.)


Thanks for the clarification.   XD

cappy2112


I have reproduced it on a Uno.

Extensive reading and testing seems to indicate what the problem is. Rather bizarrely the processor, when attachInterrupt is called, can "remember" whether the interrupt condition has already been met. Hence, if you ground the pin, and then call attachInterrupt, the interrupt fires.

This proves it:

Code: [Select]
volatile int flag = 0;

void setup() {
 Serial.begin (115200);
 digitalWrite(2, HIGH);      //pullup 2

 pinMode(13, OUTPUT);       //LED
 Serial.println ("go!");
 digitalWrite(13, HIGH);                 //time to go!
 delay (5000);
 digitalWrite(13, LOW);                 //time is up!
 
  // interrupt on
 attachInterrupt(0, isr0, FALLING);     //enable interrupt

 // did we get an interrupt?
 Serial.println (flag, DEC);
 }

void loop() {}

void isr0 () {
 flag = 1;
}


There is no detachInterrupt there. After the sketch starts and displays "go" you have 5 seconds to ground (and release) pin 2. If you do, and only if, then it displays 1, otherwise it displays 0. And this is despite the fact that you generate the "interrupt" before interrupts are enabled on that pin.

Now, add this line just before attaching the interrupt:

Code: [Select]
EIFR = 1;

That clears the interrupt flag (for interrupt 0). According to the datasheet:

Quote
The flag is cleared when the interrupt routine is executed. Alternatively, the flag can be cleared by writing a logical one to it.


So this is manually clearing the "I saw an interrupt" flag, before enabling interrupts.

Arguably, attachInterrupt should do this. And note that detachInterrupt has no effect on the flag at all.

I don't know whether there would be programs around that rely on interrupts being "pre-triggered" before you even attach the interrupt. Perhaps there are.

Note that if you are using interrupt 1, it would be:

Code: [Select]
EIFR = 2;



Thanks Nick.

I've been pulling my hair out thinking  I had some electrical issue on my project.
I had suspected it was something to do with attach/detach but couldn't nail it down.

I'm using an UNO- REV2 (does the rev make a difference for this problem)?
Which Rev did you use to duplicate this?

Should this be treated as a software bug and implemented in the compiler, so the user doesn't have to remember to clear the interrupt manually?

cappy2112


I think the documentation for attachInterrupt should be amended to strongly suggest doing the lines above. I agree that you don't expect an interrupt to immediately register from some action that you might have taken an hour ago, just because you attach interrupts. You reasonably expect them to be effective "now" not in the past.

There is also a reasonably strong case for amending attachInterrupt to do it for you. After all, attachInterrupt is supposed to be shielding you from having to know all that low-level stuff.


Agreed. Has this issue been formally reported to the maintainers of the IDE / compiler?
Perhaps it's already been fixed in 1.0, but that release apparently has enough problems to avoid using it for a while.

Nick Gammon


Perhaps it's already been fixed in 1.0, but that release apparently has enough problems to avoid using it for a while.


My copy of version 1.0 RC2 does not appear to have any mention of EIFR in attachInterrupt.

cappy2112



Perhaps it's already been fixed in 1.0, but that release apparently has enough problems to avoid using it for a while.


My copy of version 1.0 RC2 does not appear to have any mention of EIFR in attachInterrupt.


Thanks. Do we know if this issue has been officially reported to the maintainers?

Go Up