Teensy +2 general hardware interrupt question - use of pullups required on INTx pins

Status
Not open for further replies.

brianb00

Member
I have also posted this in the Arduino forum, hope this isn't too basic

Hi all, This is a general use question. I have an app. that is using a Teensy+2. I don't use interrupts. I see random stalls in the app. over periods of a few hours to a day or two. There are many causes I have ruled out. The Atmel processors have interrupt enable registers that I am not using, that is I never explicitly enable an interrupt input.

Question: Do libraries like Serial and I2C enable all interrupt inputs ? Is it possible that this is the case, and if one were to leave the two external interrupt pins floating, even though not in use, that a static induced pull down on those INTx pins could vector a program into the either ?

I have recently explicitly pulled those pins to a high state with the processor internal pullups. I have now run the app. continuously for 5 days with no failures. This appears to have solved this issue but I ask the question as I need to know the root cause to be certain all is good.

Regards,
Brian
 
The following is a very small snippet relevant to this question. The code base is too large to post here. The question is general, given the use of wire.h, and other libraries, should one pull up the interrupt external lines, if not in use, to prevent an inadvertent interrupt ?

#include <Wire.h>
#include <ITG3200.h>
#include <EEPROM.h>
#include <IRremote.h> //021412:
#include <PWMServo.h> // this is _V2, from the TEENSY 2.0 library, not the stock servo program.

// relevant set up code

pinMode(INT0,INPUT_PULLUP); // set the two external interrupt pins to have a pull up to avoid a reset by accident.
pinMode(INT1,INPUT_PULLUP);
 
It depends.

If the chip generating the interrupt is a normal digital output, which drives both low and high, and you can configure it to be driving the pin before you call attachInterrupt(), then there's probably no need for input pullup.

If it's open drain output, or otherwise leaves the pin undriven at times, the you should have a pullup, so the pin isn't ever floating.
 
If this doesn't solve your problem, perhaps you could reduce it to a small program which demonstrates the issue, without the rest of your code which isn't related.
 
Thanks Paul, but I am not using interrupts at all.

If this doesn't solve your problem, perhaps you could reduce it to a small program which demonstrates the issue, without the rest of your code which isn't related.

I don't use interrupts, nothing is connected to the external interrupt inputs. I had left them untouched physically and with the code. I get occasional machine resets (hours pass beteen mystery resets, up to 20 hours) and I have put many hours into solving. My reasoning was that maybe one of the libraries enables those external pins and since I have not explicitly pulled them up they are floating and can trigger by accident.

Feedback I have so far indicates that if an attachInterrupt() has not been executed this should not happen. Just in case I now have pulled up the lines with code. about 5 days of continuous execution and no inadvertent failures. I would like to believe I have found root cause, but given what has been said so far I don't think I can assume that. Back to testing several units in parallel with diagnostic routines inserted to capture last operational state. A very slow process.

Thanks for your inputs.
 
Status
Not open for further replies.
Back
Top