This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TSC2007: TSC2007 supurious interrupts / AUX problem

Part Number: TSC2007

I'm seeing occasional (every second or so) spurious /PENIRQ interrupts from a TSC2007 part in my design when talking to other i2c devices on the bus.  Can this be avoided?  Have others seen the same issue?

Also, the TSC2007 datasheet doesn't indicate how to connect AUX when not required.

This forum pusting from 2012 indicates that AUX should be tied to GND.

Doing so causes high frequency ringing noise on PINIRQ and the part is then unusable in that confugration.   This would indicate that AUX is "live" even when not beinv requested,

I tried this GND tie believing that the AUX may be the cause of the inwanted /PENIRQ

How have others dealt with AUX ?

  • Hello Ian,

    The AUX input can be connected anywhere within the analog input range of the pin as shown in the datasheet image below.  To clarify, is the issue that when AUX is connected to GND you receive a random PENIRQ or that when left floating there are issues?

  • Thanks for the response Colin.

    I started investigating this as one issue, but it may be two.

    1) When there's traffic on the i2C bus, I receive spurious /PENIRQ interrupts at a rate of around 2 per second.   The pattern is random, but only happens when there's I2C traffi (other devices on the bus)

    2) Tieing AUX to GND causes constant high frequency noise on /PENIRQ - the CPU sees interrupt storms

    I don't really care about issue 2 but it seems "very odd".  Issue 1 is what's causing a hassle.

    Thanks

  • Hi Ian,

    Agreed issue #2 is strange as there does not appear to be a direct connection between the AUX input and the PENIRQ control in the block diagram. Is there a large amount of GND noise that could be causing some unwanted behavior?

    There is a note in the datasheet that is a little vague but seems to suggest that the PENIRQ signal should be masked while communicating with the TSC2007. It's the last paragraph above Figure 27 on page 19 . It sounds like it, but can you confirm whether the spurious PENIRQ interrupts occur during communication with other devices?
  • Yes, the problem is when "other traffic" is on the i2c bus.  Our product has multiple devices on the bus, as is perfectly normal.  /PENIRQ during communication to the TSC2007 is a not an issue.

    Thanks,

    Ian

  • It sounds like you've confirmed the random /PENIRQ only occur while during the I2C communication timing with other I2C devices on the bus. Agreed having other devices on the I2C bus shouldn't cause issues as this is normal practice for an I2C bus.

    We haven't heard of this behavior before but will dig in to see if we can find any history of similar behavior. Since the behavior seems loosely related to the AUX input could you try connecting it to the supply voltage (VDD/REF) for the TSC2007? Also, any chance changing the PENIRQ pull-up resistor setting makes a difference?
  • Jeffray,

    We have dug through the history of these devices and have not been able to find any similar behavior. Were you able to try the different pull-up resistances or AUX input connection?
  • Hello Jeffray,

    Any updates on the pull-up values or AUX input connections?

    I will close this thread out if I don't hear back in the upcoming days.
  • I have been waiting for updated hardware with additional decoupling.  This will receive further investigation here this week.  Many thanks for your assistance.

    Ian

  • Changing the /PENIRQ pullup to 90K didn't make any difference (not surprising).

    The new board has improved ground.  The extra 1uF bypass helped significantly.   We also changed i2c pullups from 2k7 to 4k7 which finally resolved the issue spurious interrupt issue.

    AUX remains floating and I've not revisted tying it to GND again with the new board.

    I've been running for many hours now with constant chatter on the i2c bus and no spurious interrupts at all now. 

    Thanks again for the timely input to this matter.

    Ian

  • Thanks for confirming the solution Ian!