[参考译文] AM623：I2C1_SCL 保持低电平

更新了原始说明

您好、Tony、

谢谢你。

不确定这里是否有问题。

对我来说、您似乎已将您的学习成果整合在一起、看起来很好。

我的理解是否正确？

此致、

Sreenivasa.

我只添加更多背对背、问题就是 SCL 卡在低电平的原因、仍然需要 BU 专家进行分析。

我没有告诉访问不存在的设备是原因,它会返回 NACK ,不会导致挂起。

您好、Tony、

谢谢你。

此致、

Sreenivasa.

您好、Tony、

谢谢你。

我来回顾一下反馈意见。

此致、

Sreenivasa.

您好、Tony、

您能否确认上述原理图是否为客户原理图？

器件专家建议添加22R 或33R 电阻器并执行一些测试。

此致。

Sreenivasa.

您好、Tony、

1)我可以让你确认这些"挂起"有多长时间?

10ms - 100ms？

1s？

不确定？

2)客户使用哪个版本的 Linux SDK？ 他们使用的是 RT Linux 还是常规 Linux？

请记住、时钟延展是正常的、符合预期、其中 I2C 外设或 I2C 控制器在完成处理时将 SCL 保持在低电平。

在 Linux 引导期间、我观察到常规 Linux 调度程序(即、不是 RT Linux)导致 SCL 线路处于低电平的时间大于30毫秒、极少超过100毫秒。 这在非实时操作系统中是正常的。

3)请注意、只有在串行电阻两侧都有上拉电阻时、测试串行电阻任一侧的电压才有用。  

如果您只是简单地移除 R1、然后分别探测 A 和 B、则该测试无效、因为 AM62x 侧没有上拉电阻。

此致、

Nick

"挂起"是指无限期的。 由于 SCL 一直为低电平、因此无法在 I2C 总线上发送数据。  

它是 HS-AM6232上的 FS SDK9.2。  

这不是性能、延迟和吞吐量问题。 SCL 卡在低电平不是 I2C 的罕见问题、在此论坛上搜索"SCL 卡在低电平"可以获得许多类似帖子：

https://e2e.ti.com/search?q=SCL%20stuck%20low&category=forum

我也有旧 Wiki 页面的 I2C 提示、可以通过复位 I2C 模块恢复、但很容易再次发生、需要分析为什么以及导致这种"挂起"的原因

/cfs-file/__key/communityserver-discussions-components-files/791/I2C-Tips-_2D00_-Texas-Instruments-Wiki.pdf

Unknown 说：

如果您只是移除 R1、然后分别探测 A 和 B、因为 AM62x 端没有上拉电阻、则测试无效。

测试结果可证明外部器件未保持 SCL 低电平。

您好、Tony、

好的、外部设备上的公平点可能未将 SCL 保持在低电平。 我不确定在运行时移除电阻器可能会如何影响总线、因此根据该单一测试、我仍然不能随意地说 AM62x 肯定会将 SCL 保持在低电平。

原理图上的虚线框是否表示单独的子卡？

将继续离线讨论代码。

此致、

Nick

Nick、

我在2个 AM62B-SK 电路板上运行测试代码超过30小时、但尚未重现。 但10小时以上即可在定制电路板上进行生产。 我将与客户沟通。  

你好、Tony

感谢您的更新。

此致、

Sreenivasa.

您好、Tony、

感谢您的更新。

如果代码中的某个位置出现无限循环、则添加 print 语句来尝试查看驱动程序正在执行的操作可能会有所帮助。 如果您想要一些有关如何执行该操作的示例代码、请告诉我。

此致、

Nick

您好、Nick、

有2种 I2C 拉至低电平问题。

#1。 由外部从器件拉至低电平、将导致系统挂起。

客户找到一种轻松重现问题的方法、将 SDA 和 SCL 短接至低电平、会产生大量超 时或 NACK 中断、导致无法退出 WAIT_FOR_FINDY_TIMEOUT 1s 线程、然后执行系统挂起操作。

更改 dtsi MAIN_i2cn 中断=  IRQ_TYPE_EDGE_RISING 解决了问题。  

#2. 由主机本身拉低。

重置 I2C 模块、但很快就会再次重现问题(5分钟内)。

由于它仅在定制板上复制、1条 I2C 总线上有2个从器件、未在 AM62x SK  上复制、客户现在重新定位、仅在一条 I2C 总线上连接一个 I2C 器件以继续。

您好、Tony、

嗯、很有趣。 我不知道为什么从  IRQ_TYPE_LEVEL_HIGH 更改为 IRQ_TYPE_EDGE_RISING 会有什么不同...

客户是否能够 添加打印件并跟踪在 AM62x 主机将信号拉低的情况下运行的代码？

此致、

Nick

这是你想要的吗?

您好、Tony、

先关、

4月28日回复邮件中的第一个问题 ：

我不确定我是否理解。 客户说在这种情况下、他们的代码无限期挂起在 i2c-OMAP-Lc 驱动程序的这一部分？

/*
 * Low level master read/write transaction.
 */
static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
                             struct i2c_msg *msg, int stop, bool polling)
{
...
        if (!polling) {
                timeout = wait_for_completion_timeout(&omap->cmd_complete,
                                                      OMAP_I2C_TIMEOUT);
        } else {
                do {
                        omap_i2c_wait(omap);
                        ret = omap_i2c_xfer_data(omap);
                } while (ret == -EAGAIN);

                timeout = !ret;
        }

        if (timeout == 0) {
                dev_err(omap->dev, "controller timed out\n");
                omap_i2c_reset(omap);
                __omap_i2c_init(omap);
                return -ETIMEDOUT;
        }

让我感到困惑的原因是、WAIT_FOR_FINDY_TIMEOUT 的整个点是该函数将等待直到传输完成或一直等待到 OMAP_I2C_TIMEOUT (在默认驱动程序中设置为1秒)。 因此、该功能最多应该挂起1秒、继续执行该代码片段的"控制器超时"部分、并复位 I2C 总线。

客户是否能够 添加打印件并跟踪在 AM62x 主机将信号拉低的情况下运行的代码？

我正在寻找客户在 I2C 驱动程序 i2c-OMAP 中添加打印语句、以便我们可以按照代码在挂起时的位置进行操作。 这将告诉我们代码在 TI 的 I2C 驱动程序中挂起的位置(如果代码实际上挂起)。

客户的输出是否告诉我们 AIC3101驱动程序中出现了问题、并且代码在较低级别的 i2c-OMAP 驱动程序甚至被卷入之前挂起？

我不确定该驱动程序的情况。 我看到的绑定文档  
Documentation/devicetree/bindings/sound/tlv320aic31xx.txt
"TI、tlv320aic310x"-具有单声道扬声器放大器的通用 TLV320AIC31xx

但是、我在 Linux SDK 9.2、10.1或11.0中找不到 TLV320AIC3101的驱动程序本身。 如果您愿意、我可以将此主题发送给 AIC3101团队以评论他们的驱动程序。

此致、

Nick