[参考译文] MSPM0L1306：I2C 目标器件热插拔(即插即用)问题

你好、Tiger、

现在我正在查看 TRM、根据它、在 I2C 目标器件模式下、始终启用时钟延展。  那么、当您说"如果启用了时钟延展功能"时、您意味着什么？   我猜 I2C 是否挂起、因为当 I2C 模块认为它在发送/接收的过程中时、它可能在某种程度上与这些 TREQ 或 RREQ 位有关。   

目前、我想我们只需要一些超时功能并重新初始化 I2C 模块。  如果超时、我们也可以在插入 PA0时在 PA0边沿设置中断、然后知道何时重新配置 I2C 模块。   

至于 MCLKOCNTLOAD 寄存器、它似乎只用于控制器端。  您是正确的、似乎没有寄存器定义、我认为这只是一个文档错误。  我将从预量产数据表中将其链接至下方以供参考、我将与我的系统团队跟进以确认此问题是否是意外发生的、并已将其修复。   

谢谢。

JD

您好、JD：

感谢您的回答。 但是、我不同意您的说法"在目标模式下、始终启用时钟延展。。。"。

我在最新的 TRM 中看到、寄存器描述具有该字段。

我还在最新的 SDK (1.10.00.05)中看到以下函数：

__STATIC_INLINE void DL_I2C_disableTargetClockStretching(I2C_Regs *i2c)
{
    i2c->SLAVE.SCTR &= ~(I2C_SCTR_SCLKSTRETCH_MASK);
}

如果我调用它来初始化 I2C、问题就会消失。

此外、就我而言、如果我  定期拉动寄存器 I2C0->SLAVE.SSR 和 I2C0->CPU_INT.RIS 并打印它们的值、当 SCL/SDA 引脚上的上拉电阻器消失时、我看不到明显变化。 然而、同时、SCL 引脚被永远置为低电平并且不能被释放、所以阻止进一步的通信。

再次重复我的问题：

1. 我们将使用 I2C0 在 目标模式 打开 PA0和 PA1 ，我们应该如何区分远程器件被移除(上拉电阻器消失)，并在远程器件恢复时准备就绪(上拉电阻器已连接)？
2. 我们是否应该在 SCL 和 SDA 引脚上部署(外部)下拉电阻器以避免它们悬空？

嘿、Tiger、

感谢您指出 SCTR。 SCLKSTRETCH 位。  我看到 TRM 应该会显示时钟扩展"默认启用"、而不是"始终启用"。  我已经提交了反馈。  

至于 I2C 行为、我 不确定在 SDA/SCL 上拉电阻被移除时的预期行为、或者它看起来像是启动条件还是 MCU 之类的。  

在您的应用中、这种断开可以随时发生、甚至在交易中途发生、对吧？    看到此问题时、是否与何时发生与通信相关的断开相关？  我可以想象、启用时钟延展时、I2C 总线在事务中间花费的时间比禁用时钟延展时多得多。   

连接后、进行 I2C 事务的频率有多高？  或者、您希望它们之间的最长时间是多少？  

1. 我们将使用  I2C0  在  目标模式  打开  PA0和 PA1 ，我们应该如何区分远程器件被移除(上拉电阻器消失)，并在远程器件恢复时准备就绪(上拉电阻器已连接)？
   1. [ JD ] 我仍然认为超时是确定是否已删除远程控制器的最佳方法。  最简单的方法可能是使用事件发布者系统将计时器加载连接到 I2C 中断标志、因此它会自动重新加载每个事务。  超时后、我们可以检查 SDA/SCL 状态并禁用 I2C 模块。   
   2. 为了检测远程控制器的返回、最好将引脚重新配置为 GPIO、并在边沿上中断。  然后、我们可以重新初始化 I2C 模块和引脚。   

1. 我们是否应该在 SCL 和 SDA 引脚上部署(外部)下拉电阻器以避免它们悬空？
   1. [ JD ] 我相信这也可能解决这个问题。

谢谢。

JD

谢谢 JD。

在我们的用例中、可以随时发生断开连接、即使在 I2C 通信或总线空闲期间也是如此。

我按照你的建议、一直启用内部下拉电阻器(数据表中的~40K)。 I 设置以下状态机：

1. 这些引脚配置为 I2C 目标功能。 使用所需的正常中断对 I2C 模块进行复位、上电和配置。 配置 timoutA 以检测 SCL 低电平超时(0xFF)
   
   1. 我们会定期检查  I2C0->CPU_INT.RIS 和 DL_I2C_INTERRUPT_TIMEOUT_A 条件(在 main ()循环中、不要使用中断)、如果发生这种情况、我们会关闭 I2C 相关中断、关闭 I2C 模块、然后进入下一状态
2. 引脚(SCL/SDA)配置为 GPIO 输入、启用上升沿中断以检测主机器件连接。
   1. 发生中断时、禁用 GPIO 功能(和中断)、并且
   2. 移至下一个状态(从1开始)

但是、上述状态机仅工作一次(1 -> 2 -> 1)。 我们无法再次从1->2进行状态转换。 RIS 寄存器始终为0x00080000、即使 SCL 连接到低电平也是如此。 (已测试万用表、引脚对地短路、~40 Ω)。

BTW、我们 尚未更改时钟 延展设置(默认为目标启用)。

您能指出为什么我们无法在第二次设置 timeoutA 标志？

嘿、Tiger、

我不知道为什么它第一次工作、而不是第二次工作。  您使用的 I2C 初始化函数是否与第一次完全相同？  您能否分享您如何关闭 I2C 模块以及如何重新初始化该模块？

在第二个循环上、你可以检查 TIMEOUT_CTL 寄存器、也许还可以检查 TIMEOUT_CNT。 TCLTA 来查看当前超时计数是多少？

说实话、我之前并未亲自使用 I2C 的内置超时特性、我也不确定此特性、这是因为从技术上讲、它是针对 I2C 模块的"控制器"一侧。  实际上、我建议使用 TIMGx 或 WWDT 计时器设置一个外部超时、并在每个周期性 I2C 中断重新加载它。  不管它是什么、即使它只是一个 RX 完整 ISR 或 FIFO 中断。  除了直接监控 SCL 线路、我们只需调整计时器、以便当事务在 X 段时间内没有发生时、就可以触发中断或设置 ISR 标志。  

您是否有 TIMGx 或 WWDT 备用吗？  或者、我们也许可以轻触现有的解决方案？   

如果您不这样做、并且我们必须使该 I2C 超时计时器正常工作、请告诉我、我将帮助您进一步深入探究。   

谢谢。

JD

您好、JD：

我想在最新的 TRM 中、控制器和目标之间的描述变得一团糟。

• 在 SMBus 下键入关键字"timeout check"。
• 16.2.3.6时钟低电平超时(CLKTO)、寄存器映射在0.57.00.00和1.10.00.05之间变化。 我不确定 IC 是否更改了此器件、TRM 上的描述似乎并不反映最新的 SDK。
  • 0.57.00.00 I2Cx->MASTER.MCLKOCNT 和 I2Cx->MASTER.MCLKOCNTLOAD (较新版本中保留了相同的地址)
  • 1.10.00.05 I2Cx->TIMEOUT_CTL 和 I2Cx->TIMEOUT_CNT (旧版本中保留了相同的地址)
  • 如果我拉取生产 IC & SDK 上的旧地址(保留)、结果始终为0。
  • 为什么寄存器从"主"寄存器组中移出？ 它是否指示控制器(主器件)和目标器件(从器件)都具有此超时功能？

我认为定期检查 I2C 通信是不可行的、因为我们无法保证 主机器件定期与目标器件通信。

随附简化代码。

e2e.ti.com/.../i2c_5F00_init.c

嘿、Tiger、

感谢您分享简化代码。  我没能评论它,但我会尽我的最大努力审查它今晚或明天的第一件事。   

谢谢。

JD

我有一个相关的问题、如果 目标 STXFIFOTRG 位被置位、中断标志是否会通过不执行任何操作来清除？ (进入和、退出中断例程、但未填充 TXFIFO 或明确清除标志)、中断是否会再次生成？
我观察到一些情况、当我们在 ISR 代码中处理该中断时、持续发生相同的中断。 例如、有 SRXFIFOTRG 中断、当 我们从 RXFIFO 读取时、STXFIFOTRG 会在退出 ISR 例程之前发生。 由于 STXFIFOTRG 位置位、SCL 引脚受到冲击、目标正在等待填充 TXFIFO。 但是、ISR 并未进入、因此我们无法执行 TXFIFO 填充代码。

嘿、Tiger、

然后继续。  我还没有深入了解这一点、但本周早些时候、你和团队就好像在同步中一样、一切都在正常工作。   

是这样、还是这个问题或其他问题仍然悬而未决？   

谢谢。

JD