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.

TCA6416A: TCAL6416 Interrupt clear vs. risk to miss an interrupt

Part Number: TCA6416A
Other Parts Discussed in Thread: TCAL6416, TCA8418E, TCA6416

Hi,

We want to use the TCA(L)6416A as an IO Expander of which a many IO's are used as input.

The interrupt output is used to avoid polling, but we can't accept the risk of missing an interrupt when a pending interrupt is cleared during the ACK/NACK of a I2C read cycle, as stated in the datasheet of the TCA6416A, page 9.

Are there options to eliminate this risk without adding additional hardware?

Thanks,

Bert

  • The interrupt can be reset if it happens during an ACK, or if the input goes back to its old value.

    To avoid this, you would need additional hardware.

  • Hi Bert,

    To gain further understanding of the situation, you are concerned specifically when an input changes from the original state (therefore triggering an interrupt) during the 9th clock cycle of the i2c bus ACK/NACK bit during a read operation of the input port register? 

    Regards,

    Tyler

  • Tyler, Clemens,

    Thanks for the reply.

    Yes, we are concerned about missing input changes during the ACK/NACK of a read cycle. We consider to use i.e. 74HCS373 Latch in front of the inputs. The latch can be disabled by SW before the interrupt is handled and enabled afterwards. However, SW isn't happy because this requires changes in off-the-shelf software. Any suggestions?

    BR,

    Bert

  • Hi Bert,

    I don't see any feature set that would detect or latch an interrupt during the ACK/NACK bit from the added functionality inside the TCAL6416. I would agree with Clemens here that additional hardware would most likely be needed such as your suggestion with the 74HCS373. 

    I did find this thread here of a similar question.

    To Bobby's point, the TCA8418E could be used since it contains a 10-byte FIFO that could keep track of inputs including inputs during the ACK/NACK bit up to a certain threshold. Of course if there are multiple inputs past the 10-byte FIFO limit, the FIFO would shift out the first bytes of data, or throw away anything >10 Bytes. 

    As for the TCA7408, the only problem I have with this solution is that I don't know the long term sourcing of this part. I wouldn't be surprised if this device were to end of life in the future. I do not see EOL problems with the TCA8418E or any of our TCA/TCAL IO expander lineup. 

    Regards,

    Tyler

  • Hi Tyler,

    Thanks for the suggestion, I will have a look on it. For now it is clear that we must foresee extra hardware if we want to use the TCA6416. No problem, just good to know.

    Thanks,

    Bert