你好！
我们一直在尝试通过 I2C 与 DLPC150通信，但它往往会锁定总线。
具体情况如下。 我们等待 HOST_IRQ 降低，然后尝试通过 I2C 发送一些命令。
通常在收到地址(并对其进行堆栈)后，DLPC150会将 SCL 线路拉低并保持这种状态。 有时，它还可以接收一个或两个数据字节(我们尝试发送不同的命令，因此传输哪些数据似乎无关紧要)。 要恢复对 I2C 总线的控制，我们必须使用 PROJ_ON 信号重置设备。
此 SCL 问题与 DLPC150相关，因为同一总线上的其他设备可以正常通信，我们还从 DLPC150断开了 SCL，以查看其线路是否处于低位。
首先，Arduino 出现了此问题，我们尝试了时钟频率为5至100 kHz 的 I2C。 在探测信号时，我们发现 I2C 正时不是最好的(SDA 在 SCL 的下降边缘发生变化，它在任何可测量的时间内都无法保存在 SCL 下降边缘之后有效的数据)。 Arduino 有一个示波器图像，其中 DLPC150接收地址并创建 ACK，但 SDA 线存在明显的小抖动。 因此我们认为锁定问题是由于 Arduino 的 I2C 计时不良导致的。 整个过程中 host_IRQ 保持较低(因此 DLPC150不报告任何错误)，但在地址字节后 SCL 被拉低。
然后我们继续使用 Raspberry (I2C @ 100kHz)。 覆盆子具有更好的 I2C 时间，因为 SDA 和 SCL 线路之间有更多的时间变化。 整个过程中 host_IRQ 保持较低，但事务结束后，DLPC150会保持 SCL 较低(已附加映像)。
我们使用两个 DLPC150进行了测试，两个设备出现相同的通信问题。 电源不应该是问题，主板是由实验室电源供电的。
我们以前使用过 DLPC150和 STM32 I2C，所以我们知道它是有效的。 令人担忧的是，我们不知道这种 I2C 锁定的原因是什么，它是否仅与 I2C 定时相关？ 即使 I2C 时间安排不佳，锁定总线似乎仍有一些苛刻的反应，我们希望 NACKing 或忽略这项交易。
您以前是否有过如何避免此问题的经验？ 似乎 以前曾有过类似的讨论，但在发布解决方案之前，该主题已经结束 ， 而 DLPC350的另一个类似主题也是如此。
感谢您的帮助，期待您的回复！
