• 状态
  • 已锁定 已锁定
  • 回复 3 回复
  • 订户 0 订户
  • 视图 30 视图
  • 用户 0 会员在此处
选项
选项
相关

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：1kHz 输入频率下中断丢失-&quot；Stlock&quot；NVIDIA Orin NX 的 INT 线路行为

admin
Guru**** 2779905 points

Other Parts Discussed in Thread: TCA6416, TCA6416A, TCAL6416

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1605587/tca6416-interrupt-missed-at-1khz-input-frequency---stuck-int-line-behavior-with-nvidia-orin-nx

器件型号： TCA6416
主题中讨论的其他部分：、 TCAL6416

尊敬的 TI 团队：

我们使用的是 TCA6416 GPIO 扩展器与连接 NVIDIA Orin NX 继续讨论。 尽管数据表提示器件具有极低延迟 (~μ s 4µs)、但我们面临着一个问题、即当输入信号频率接近 1kHz（1ms 间隔）时、中断会丢失。

系统配置：

  • 主持人： NVIDIA Orin NX（基于 Linux）

  • 器件： TCA6416

  • 接口： I2C（配置为 400kHz）

  • 输入： 引脚 P0.0 配置为外部信号每 1ms 切换一次的输入。

  • 中断线路： TCA6416INT 引脚连接到 Orin NX 上的 GPIO（配置为低电平有效）。

问题： 当向 P0.0 提供 1ms 的中断脉冲时、我们会观察到在主机端不能可靠地触发中断。

该INT行似乎没有足够快地取消置位（返回高电平）。 我们的测试表明、系统需要的延迟为 ~5-7ms 相互比较以可靠地捕获每个事件。 如果输入速度快于此速度、则INT引脚保持低电平（有效）、从而有效地屏蔽后续脉冲。

我们的分析： 我们知道 TCA6416INT 在引脚状态发生变化时置为低电平、仅在之后释放 输入端口寄存器 读取或引脚状态恢复到原始值（取决于锁存器配置）。

我们怀疑、瓶颈可能是 Linux I2C 驱动程序确认中断并执行清除INT线路所需的特定 I2C 读取事务所需的时间。

问题：

  1. INT收到 I2C 读取命令后、能否确认 TCA6416 内部逻辑的最短内部复位时间？

  2. 对于该器件上的高频轮询/中断清除、是否建议使用特定的“批量读取“或优化的寄存器访问方法？

  3. 如果 I2C 读取恰好在发生新的输入转换时发生、是否有任何有关“中断屏蔽“的已知勘误表？

image.png

如有任何关于尽可能减小“INT 清除“延迟的见解、请不胜感激。 在本例中、我们无法承受~5-7ms 的时间。

谢谢、
Cibi.P

  • 0
    TI__Guru**** 2779905 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Cibi：

    我似乎无法上传.png。  

    该INT行似乎没有足够快地取消断言（返回高电平）。 我们的测试表明、系统需要的延迟为 ~5-7ms 相互比较以可靠地捕获每个事件。 如果输入速度快于此速度、则INT引脚保持低电平（有效）、从而有效地屏蔽后续脉冲。[/报价]

    /INT 是开漏输出。 逻辑高电平速度由所使用的上拉电阻决定。 您是否尝试过针对 IOL 电流消耗更强的上拉至 3mA？  

    此致、

    Tyler

  • 0
    TI__Guru**** 2779905 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Tyler Townsend ：




    尊敬的 Tyler Townsend ：

    我们遇到与 TCA6416A 上的中断传播相关的时序问题。 在我们当前的设置中、MCP2518FD CAN 控制器连接到 TCA6416A GPIO 扩展器、然后向运行 Linux 的模块上系统 (SOM) 发出中断信号。

    问题

    当初始中断在数据表中提到的（数据有效到中断）规范内成功传输 (~4µs) 时、不会捕获每 1ms 发生的连续中断或将其正确传输到 SOM。

    我们观察到、系统需要中断之间至少有 5ms 的延迟才能可靠地运行。 但是、我们的应用需要处理 CAN 帧 TX/RX 处理的 1kHz 中断率（每 1ms 一次）。

    故障排除和观察

    为了找出根本原因、我们执行了以下步骤：

    • 直接连接测试：我们绕过 TCA6416A 并将 MCP2518FD 中断引脚直接连接到 SOM GPIO。 在此配置中、系统在 1kHz 频率下运行良好。

    • 上拉电阻器修改：我们已经尝试在 INT 线路上实现更强的上拉电阻。 我们认为这不是问题、因为第一个中断始终会在预期的 4µs 窗口内与 SOM 进行通信。 故障仅发生在后续脉冲上。

    问题

    1. 端口寄存器读取（清除中断）后、INT 输出是否需要特定的“恢复时间“才能重新置为有效？

    2. 如果 MCP2518FD 在 I2C 控制器仍处于第一个中断的“清除“读取操作过程中触发第二个中断、TCA6416A 如何处理此问题？

    3. 是否建议使用特定的 Linux 驱动程序配置或 I2C 时钟速度（我们当前使用的是 400kHz）、以确保中断服务例程足够快地清除、从而捕获 1ms 的间隔？


    此致、
    Cibi P

  • 0
    TI__Guru**** 2779905 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Cibi：

    [报价 userid=“680837" url="“ url="~“~/support/interface-group/interface/f/interface-forum/1605587/tca6416-interrupt-missed-at-1khz-input-frequency---stuck-int-line-behavior-with-nvidia-orin-nx/6190136

    • 端口寄存器读取（清除中断）后、INT 输出是否需要特定的“恢复时间“才能重新置为有效？

    • 如果 MCP2518FD 在 I2C 控制器仍处于第一个中断的“清除“读取操作过程中触发第二个中断、TCA6416A 如何处理此问题？

    [/报价]

    问题 1 和 2 可能与 TCA6416A 数据表的这一部分相关：  

    是否建议使用特定的 Linux 驱动程序配置或 I2C 时钟速度（我们当前使用的是 400kHz）、以确保中断服务例程清除得足够快、能够捕获 1ms 的间隔？

    400kHz 是此器件支持的最大值（快速模式 I2C）。  

    如果您想按 1MHz 进入快速模式+、则需要切换到 TCAL6416。 然而、在 VCC 上、该器件仅建议在高达 3.6V 的电压下运行。  

    此致、

    Tyler