• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 19 subscribers
  • Views 9193 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TCA6408 & PCA9534 Interrupt issue

Thomas Søhus
Prodigy 80 points
Other Parts Discussed in Thread: PCA9536, TCA6408, PCA9534, PCA9534A, TCA6408A, PCA9535, TCA6424

I am experiencing problems with the interrupt signal from the TCA6408 I2C IO expander, which seems to be an IC issue. A similar although not identical problem is experienced with the PCA9536 I2C IO expander. Here are my obervations:

TCA6408:

1. After reset of the IC when I flip an IO, I will get an interrupt signal whenever the signal is different from the port value it had during reset (or after last read). This is as expected!
2. However after having had any kind of communication on the I2C bus to which the TCA6408 is connected, the interrupt line is no more active, and no interrupts can be triggered anymore no matter what you do.

The observation is that after any activity on the I2C bus, the Interrupt line is no longer effected by any change on the IO's. This happens even if the activity on the I2C bus is not addressing any present device on the bus (i.e. no ACK on the bus).


PCA9534:

1. After reset of the IC when I flip an IO, I will get an interrupt signal whenever the signal is different from the port value it had during reset (or after last read). This is as expected!
2. However after having received an I2C ACK from any device on the I2C bus the interrupt line is de-asserted.

The observation is that the device does not only de-assert the IRQ line when the PCA9534 it self sends and ACK on the l2C bus, but also when other devices send an ACK on the I2C bus.

Both issues seems as a design/implementation issue of the IC. Is this a known problem of these devices?

Best regards,
Thomas Søhus

  • 0
    TI__Genius 9085 points

    Hello Thomas,

    Yes, we have seen similar behavior with both these devices. They have been re-released as the TCA6408A and the PCA9534A.

    http://focus.ti.com/docs/prod/folders/print/tca6408a.html

    http://focus.ti.com/docs/prod/folders/print/pca9534a.html

    If you are using the older, 'non-A' versions, I suspect a switch to the A version will clear up these problems. The parts are identical pin-out and functionality, but the issues you are describing have been corrected.

    I have also included a description of the software solutions to these issues below if you would prefer software changes to switching parts.

     

     

    Software Solutions:

    TCA6408:

    Any stop on the I2C bus (even from another device) will clear the interrupt on the TCA64xx. There may be a software work around if you do not want to switch parts. For the the TCA6408,  adding one more SCL clock pulse after a STOP signal will capture the interrupt. 

     

     PCA9534:
    The INT will de-assert when:
    •The last I2C command byte (register pointer) written was 00h. This generally means the last operation with the device was a read of the input register, but the command byte may have been written with 00h without ever going on to read the input register
    •Any other slave device on the I2C bus acknowledges an address byte with the R/W bit set high. This occurs when reading any other valid device on the bus.
    The software work around for this is changing the command byte to something other than 00 (hex) after a read operation to the PCA9534.

  • 0 in reply to Hattie
    Prodigy 80 points

    Hi Hattie,

     

    Thanks for you answer. I have not tried the TCA6408A yet but the problem above was however observed on a PCA9534A device. Can you positively confirm which devices TCA and PCA where this problem have been solved?

     

    I am not sure I fully understand the software work arounds that you describe above.

     

    TCA6408:

    Do you mean to say that if I add an extra SCL clock cycle after the STOP condition on the bus, then the Interrupt will be correctly asserted by the TCA6408?

    I am not really comfortable with this approach since I have to add this extra "non-standard" SCL clock cycle to all communication with other devices.

     

    PCA9534(A):

    Whenever I read from another device the Interrupt from PCA9534(A) is disabled. Do You mean to say that if the last command (prior to the interrupt generation) was different from command 0x00 (e.g. a read of the PCA9534(A) configuration register (0x03)) then the Interrupt generation issue would not occur?

     

    Thanks for clarifying,

    Best regards,

    Thomas

  • 0 in reply to Thomas Søhus
    TI__Genius 9085 points

    Thomas,

    I'm sorry, I was mistaken;  the PCA9534A has the same issues as the PCA9535.  After double checking with the design group I can confirm that the TCA6408A has corrected for the INT problem you are seeing. 

     

    TCA6408:

    Yes, an aditional clock would have to be added after every stop event from every device. Switching to the TCA6408A is likely your best option.

     

    PCA9534:

    If any device generates an ACK and the last PCA9534 command was 0X00, the INT will de-assert. According to the information I have, if the last command is not 0X00, (e.g. a read of the PCA9534(A) configuration register (0x03), like you describe,) the INT de-assert should not occur.  

    So, if after every read from the input, 0x00, you perform a read from the configuration register, 0x03, before resuming normal bus communication, ACKs from other devices should not reset the PCA9534 .

    Please let me know if you observe different behavior or there are further clarifications I can make.

  • 0 in reply to Hattie
    Prodigy 80 points

    Hi again Hattie,

     

    TCA6408A:

    I have now had the time to verify that the TCA6408A does indeed solve the above mentioned issue :-) I have not tested it extensively yet, but everything seems to work as intended. I will let you know in case I find any (other) issues.

    PCA9534A:

    I tried the software work around that you described above for the PCA9534A, but I could not get it to work. The PCA9534A de-asserts the interrupt line, as soon as it sees an ACK on the bus, no matter what the last command sent to it was (e.g. 0x3).

     

    Based on the above, I have changed my design (drop in replacement for TCA6408) to use TCA6408A.

     

    Thanks again for your valuable help,

    Best regards,

    Thomas

  • 0 in reply to Thomas Søhus
    TI__Genius 9085 points

    Thomas,

    I am glad to hear the TCA6408A is working for you.

    If it is not inconvenient, I would be curious to see some waveforms from the PCA9534 device.

     

    Just to further clarify, and for others who may come across this issue:

    The important part of the debug is that the RW bit goes low. During a normal read sequence this should happen as below. 

     

    A write should work as well, though I suggested the read command as it seems most convenient.

     

    Thank you for your patience with this issue, and please let me know if there are further questions.

     

     

     

  • 0 in reply to Hattie
    TI__Genius 11475 points

    I noticed a new revision of the TCA6424 data sheet includes a description of needing an additional SCL clock to capture the INT. Is there a "A" version of this device planned to correct this device as well. As mentioned in the earlier post, adding an additional clock cycle is not convenient.