• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 34 subscribers
  • Views 350 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TCA6416: Interrupt missed at 1kHz input frequency - "Stuck" INT line behavior with NVIDIA Orin NX

Josel Go
Expert 7355 points

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

Hi TI Team,

We are using the TCA6416 GPIO Expander interfaced with an NVIDIA Orin NX module. We are facing an issue where interrupts are being missed when the input signal frequency approaches 1kHz (1ms interval), despite the datasheet suggesting the device has very low latency (~4µs).

System Configuration:

  • Host: NVIDIA Orin NX (Linux based)

  • Device: TCA6416

  • Interface: I2C (configured at 400kHz)

  • Input: Pin P0.0 is configured as an input with an external signal toggling every 1ms.

  • Interrupt Line: The TCA6416 INT pin is connected to a GPIO on the Orin NX (configured as Active Low).

The Issue: When providing a 1ms interrupt pulse to P0.0, we observe that the interrupts are not reliably triggering on the Host side.

It appears that the INT line is not de-asserting (returning High) fast enough. Our testing suggests that the system requires a delay of ~5-7ms between interrupts to reliably capture every event. If the inputs come faster than this, the INT pin remains Low (active), effectively masking subsequent pulses.

Our Analysis: We understand that the TCA6416 asserts INT Low upon a pin state change and releases it only after the Input Port Register is read or the pin state returns to the original value (depending on the latch configuration).

We suspect the bottleneck might be the time it takes for the Linux I2C driver to acknowledge the interrupt and perform the specific I2C Read transaction required to clear the INT line.

Questions:

  1. Can you confirm the minimum internal reset time for the INT logic inside the TCA6416 once the I2C Read command is received?

  2. Is there a specific "bulk read" or optimized register access method recommended for high-frequency polling/interrupt clearing on this device?

  3. Are there any known errata regarding "Interrupt Masking" if an I2C Read occurs exactly as a new input transition is happening?

image.png

Any insights on minimizing the "INT Clear" latency would be appreciated. we can't afford ~5-7ms in this case.

Thanks,
Cibi.P

  • 0
    TI__Guru 65368 points

    Hi Cibi,

    I cannot seem the .png uploaded. 

    Josel Go said:
    It appears that the INT line is not de-asserting (returning High) fast enough. Our testing suggests that the system requires a delay of ~5-7ms between interrupts to reliably capture every event. If the inputs come faster than this, the INT pin remains Low (active), effectively masking subsequent pulses.

    /INT is an open-drain output. The logic high speed is determined by the pull-up resistor used. Have you tried a stronger pull-up up to 3 mA of IOL current draw? 

    Regards,

    Tyler

  • 0 in reply to Tyler Townsend
    Prodigy 10 points

    Hi  ,




    Hi  ,

    We are experiencing a timing issue regarding the interrupt propagation on the TCA6416A. In our current setup, we have an MCP2518FD CAN controller connected to the TCA6416A GPIO expander, which then signals an interrupt to our System on Module (SOM) running Linux.

    The Problem

    While the initial interrupt is successfully transferred within the (Data Valid to Interrupt) specifications mentioned in the datasheet (~4µs), consecutive interrupts occurring every 1ms are not being captured or transferred correctly to the SOM.

    We have observed that the system requires a minimum delay of 5ms between interrupts to function reliably. However, our application requires handling a 1kHz interrupt rate (every 1ms) for CAN Frame TX/RX processing.

    Troubleshooting & Observations

    To isolate the root cause, we performed the following:

    • Direct Connection Test: We bypassed the TCA6416A and connected the MCP2518FD interrupt pin directly to the SOM GPIO. In this configuration, the system works perfectly at the 1kHz frequency.

    • Pull-up Resistor Modification: We have already tried implementing a stronger pull-up on the INT line. We do not believe this is the issue, as the very first interrupt always communicates to the SOM within the expected 4µs window. The failure only occurs on the subsequent pulses.

    Questions

    1. Is there a specific "recovery time" required for the INT output to re-assert after a Port Register read (which clears the interrupt)?

    2. If the MCP2518FD triggers a second interrupt while the I2C controller is still in the middle of the "Clear" read operation for the first interrupt, how does the TCA6416A handle this?

    3. Are there specific Linux driver configurations or I2C clock speeds (we are currently using 400kHz) recommended to ensure the interrupt service routine clears fast enough to catch 1ms intervals?


    Thanks & Best regards,
    Cibi P

  • 0 in reply to Cibi P
    TI__Guru 65368 points

    Hi Cibi,

    Cibi P said:

    • Is there a specific "recovery time" required for the INT output to re-assert after a Port Register read (which clears the interrupt)?

    • If the MCP2518FD triggers a second interrupt while the I2C controller is still in the middle of the "Clear" read operation for the first interrupt, how does the TCA6416A handle this?

    Questions 1 and 2 might relate to this section of the TCA6416A datasheet: 

    Cibi P said:
    Are there specific Linux driver configurations or I2C clock speeds (we are currently using 400kHz) recommended to ensure the interrupt service routine clears fast enough to catch 1ms intervals?

    400kHz is the maximum this device supports (Fast mode I2C). 

    If you want to push 1 MHz for fast mode +, you would need to switch to TCAL6416. However, this device only operates up to 3.6V recommended on VCC. 

    Regards,

    Tyler