Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 8 of 8

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

  1. #1
    Member
    Join Date
    Mar 2013
    Location
    Silicon Valley
    Posts
    21

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

    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

  2. #2
    Senior Member
    Join Date
    Jan 2013
    Posts
    966
    Post code, please!

  3. #3
    Member
    Join Date
    Mar 2013
    Location
    Silicon Valley
    Posts
    21
    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);

  4. #4
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    24,764
    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.

  5. #5
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    24,764
    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.

  6. #6
    Member
    Join Date
    Mar 2013
    Location
    Silicon Valley
    Posts
    21

    Thanks Paul, but I am not using interrupts at all.

    Quote Originally Posted by PaulStoffregen View Post
    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.

  7. #7
    Senior Member
    Join Date
    Jan 2013
    Posts
    966
    IIRC the IRremote.h library is interrupt driven.

  8. #8
    Member
    Join Date
    Mar 2013
    Location
    Silicon Valley
    Posts
    21
    Quote Originally Posted by Headroom View Post
    IIRC the IRremote.h library is interrupt driven.
    Good point, I will look into that angle.

    Brian

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •