I have a board based on the ATMega 12846p. I have a chip connected to the INT2 pin, and when this device brings the INT2 pin low an interrupt is indeed generated. I also have the card detect line of an SD card connected to port PA7 (Arduino digital pin 24). When I plug the card in, it also triggers the interrupt. I have checked the hardware carefully, there is no short of any type between the pins.
This is on Arduino 1.0.
Below is the code.
Any ideas?
Thanks...
attachInterrupt(INT_2, isrInt2, CHANGE);
/* Further down the file... */
void isrInt2(void)
{
sei(); // Put interrupts back up
void closeLogFiles(void);
pinMode(LED_INFO, OUTPUT);
pinMode(LED_ERROR, OUTPUT);
int state = LOW;
for(;;)
{
state = !state;
digitalWrite(LED_ERROR, state);
digitalWrite(LED_INFO, !state);
delay(100);
}
}
Just in case this is helpful ... I believe you can trigger an interrupt without any external hardware by configuring the pin as an output and then toggling it. You may be able to use the technique to determine if there is a bug and to ensure everything is working as expected.
Why do do you enable interrupts inside your ISR?
not normally necessary unless there's a compelling reason
Also, the interrupt number and pin number ARE different
Pin 2 generates INT0, not INT2
mmcp42:
Why do do you enable interrupts inside your ISR?
not normally necessary unless there's a compelling reason
Also, the interrupt number and pin number ARE different
Pin 2 generates INT0, not INT2
Oh I was just experimenting with putting interrupts back up. I originally had some code in there to flash LEDs on a delay as a visual indicator that the ISR had been entered, and of course delay needs interrupts up. Also, closing files with SDFat may need interrupts up, but a quick look at that code makes me think it does not.
This is a 1284p uC, and INT2 is physical pin 42 and Arduino D2. Trapping D2 does cause the ISR to be called. But so does PA7 (physical pin 30, Arduino pin D24). That's the mystery, why D24 calls it also.
I put a lot of test code into the ISR to read the registers of the device that is triggering the interrupt. Reading things like the register that reports what caused the interrupt seems to indicate that the device is not set up correctly. I think what is happening is that inserting the SD card causes a very brief current drop, and causes the device to reset.
I coded around it by establishing the handler after the card is known to be inserted. I don't need it before then anyhow.