[参考译文] AM2634：I2C 外设行为因任务优先级而异

尊敬的 Alessandro：

让我尝试在我这边重现这个问题 我不知道在我的头上有任何这样的问题。

1. 正如我们在某些情况下观察到的那样、这种行为是否会导致 I2C 从设备冻结？

是、这是可以实现的。 如果从器件需要持续连接且没有时钟延展、则可能会出现故障/冻结。

此外、您能否帮助我说明所使用的 I2C 地址（并不是因为它直接很重要，而是想确认 I2C 总线上是否正确共享了两个地址？）

此致、
Shaunak

从器件地址为 0x51、这是此 i2c 总线上的唯一器件。

此致

尊敬的 Shaunak：

我只是想跟进并询问是否有任何关于该问题的更新。 您是否能够在您的最终重现行为？

如果您需要我方面的任何其他信息、请告诉我。

此致、
Alessandro

尊敬的 Alessandro：

对不起,我一直忙于一些正在进行的调试,无法更早地研究它,我还没有重现这个问题,并有一个更深入的了解。 我在办公室里工作的时候、明天就要深入研究一下。

总体来说、我认为 AM26x 上的 I2C 传输非常依赖 R5F CPU 被调用、CPU 不足、因此在低优先级任务的情况下运行不正常。 虽然 I2C 控制器实际上负责执行传输、但驱动器对 CPU 非常敏感、因此字节之间的延迟违反了从器件的预期、我们可以看到线路上的从器件断开/冻结。

也许我需要检查的一件事是、在回调模式和中断模式下的行为是相同的吗？ 这绝对是 DMA 可以克服的问题。

另一点是、我们尚未在软件 I2C 驱动程序中集成 DMA（HW 支持它）、一旦我们集成 DMA、对 R5F CPU 的依赖就会减少。 硬件不会完全传输所有数据、必须涉及 R5F 来进行数据移动、处理中断等（例如，对于发送或接收的每个字节，必须涉及 CPU、因此现在几乎没有 DMA 的 I2C 字节由 CPU 处理）

此致、
Shaunak

尊敬的 Shaunak：

再次感谢您的详细答复。

关于中断模式：这实际上是我们的初始选择、但由于更频繁的问题、我们不得不放弃它。 在我们的测试中、I2C 帧通常已损坏、从而使通信不可靠。 我们还注意到其他用户报告了中断模式的类似问题、例如在本线程中：
AM2634-Q1：在 AM2634 的中断模式下使用 I2C 从 DS1307 RTC 读取全部 7 个字节

为了更好地理解您的解释、我有几个问题：

• I2C 时钟是否也由软件管理？
• I2C 外设是真正的硬件外设、还是使用由软件控制的 GPIO 的软件仿真？

此外、您还提到 DMA 有助于克服这些问题。 您能否分享有关 DMA 模式的更多详细信息？ 具体来说：

• 它将如何改变当前的行为？
• 您是否对软件驱动程序中什么时候可能提供 DMA 支持有任何估计？

最后、我们是否可以同时考虑任何建议的权变措施或替代方法来避免此问题？

再次感谢您的支持！

此致、
Alessandro

尊敬的 Alessandro：

此外、您还提到 DMA 有助于克服这些问题。 您能否分享有关 DMA 模式的更多详细信息？ 具体来说：

• 它将如何改变当前的行为？
• 您是否对软件驱动程序中什么时候可能提供 DMA 支持有任何估计？

[/报价]

-在 DMA 模式下,预期 CPU 的参与较少,这意味着无论执行 I2C 的任务优先级如何,它都不会有抖动
-我将与开发团队确认一下 I2C DMA 驱动程序的 SDK 版本

为了更好地理解您的解释、我有几个问题：

• I2C 时钟是否也由软件管理？
• I2C 外设是真正的硬件外设、还是使用由软件控制的 GPIO 的软件仿真？

[/报价]

据我所知、这是一个真正的外设、而不是 GPIO 仿真。 时钟配置一次、然后硬件应对其进行控制。 下面我介绍一些硬件专家。

此致、
Shaunak

[/quote]

我已与我们的硬件专家确认、

I2C 时钟在 SW 中配置一次、不会由 SW 持续控制

2.它是真正的 I2C 硬件,而不是 GPIO 仿真

此致、
Shaunak

尊敬的 Shaunak：

感谢您确认 I2C 外设是真正的硬件、并且在软件中配置了一次时钟。

鉴于此、我仍然对我们观察到的行为感到困惑：
为什么 I2C 时钟波形在事务期间根据任务优先级发生变化？
这表明系统中的某个器件（可能是 CPU 负载或任务调度）仍然影响 I2C 信号的时序、即使时钟应由硬件驱动也是如此。

这种行为对我们至关重要、因为它似乎是导致我们遇到通信问题和从器件冻结的根本原因。 这可能是由于您之前提到 CPU 过度参与逐字节传输所致吗？

我们如何修复或解决当前软件栈中的这种行为？
无论是使用不同的传输模式、还是在 DMA 支持可用之前实施权变措施、我们都乐于提供建议。

此外、有关何时将 DMA 支持集成到 I2C 驱动程序中的任何更新或时间安排对于我们的规划都非常有帮助。

再次感谢您的支持—我们非常感谢您在解决此问题时提供的见解和帮助。

此致、
Alessandro

尊敬的 Alessandro：

我们的专家是 OOO、请期待下周中旬收到回复。

尊敬的 Alessandro：

为什么 I2C 时钟波形在事务期间根据任务优先级发生变化？

I2C 事务被具有更高优先级的任务中断或阻止、但除非特意重新配置、否则不应更改 I2C 时钟 (SCL) 频率（例如 400kHz 或 100KHz）。 我将运行一个测试、检查 SCL 是如何变化的。

这可能是因为 CPU 太参与了逐字节传输吗？正如您之前提到的那样？

您是对的。 在我看来、I2C 占用的带宽很大。 如果您的应用没有发送或接收太多数据、您可以将任务配置为低优先级、因此在 I2C 事务处理过程中、它不会缺少更重要的任务。

我们如何在当前软件栈中修复或解决此问题？

如果不得阻止应用中的 I2C 事务、请将 I2C 任务配置为更高优先级。 另一种方法是暂停可能中断 I2C 事务的任务。

每当任务被挂起时、它都会保持 被阻止状态、直到再次恢复该任务。  

此外、有关何时将 DMA 支持集成到 I2C 驱动程序中的任何更新或时间表对我们的规划都非常有帮助。

尊敬的 Alessandro：

这是定制板还是 TI LaunchPad/控制卡？

此致、
Shaunak

尊敬的 Alessandro：

今天是否可以拨打电话？ 我将通过电子邮件共享会议邀请。 请告诉我您什么时候有空？

此致、
Shaunak

当然！ 我们的可用时间为 17.00 CEST。

完美、让我通过电子邮件将邀请分享给您、请将邀请转发给所有必要的人、  

此外、您能通过电子邮件向我分享定制电路板的原理图吗？ TI 团队以前是否曾审查过原理图？

此致、
Shaunak

尊敬的 Alessandro：

由于我们正在通过电子邮件进行对话、因此请在 E2E 上关闭此主题。 如果需要、您可以重新打开螺纹。 该团队正在研究 I2C DMA 模式的实施、并将在 1-2 天内通过电子邮件分享估计工作量和进一步意见。

此致、
Shaunak