[参考译文] TPS25750：无法识别的模式值

尊敬的 Jeff：  

我们将对此进行深入探讨、并向您提供详细信息。  

由于此问题不容易复制(您提到了大约5000次试用)、 这可能只是一个临界情况问题。 当您的 MCU 读取 MODE 寄存器时、TPS25750是否会在任何时候掉电(通过 VIN_3V3或 VBUS)？

谢谢。此致、

Raymond Lin

您好、 Raymond—感谢您一如既往的及时支持。

在另一次~10,000次试验后、我再次重现了该问题；这一次、我将一个逻辑分析仪连接到支持 TPS25750的 I2C 总线。 在 I2C 读取期间、当我们的处理器在两个字节之间短暂停顿时、似乎会出现该问题、如下所示：

这种情况并不常见、但如果我们的处理器长时间处理另一个高优先级中断、则可能会发生这种情况。 通过监测时钟电平上的细微差异、我们可以确认产生延迟的是我们的处理器而不是  TPS25750：

返回下一个字节到最后一个字节后、 TPS25750时钟延展不到30us；由于时钟的振幅稍低(TPS25750 和处理器并行驱动)、可以明显看出这一点。

此后、 TPS25750 释放时钟；振幅略有增加、因为只有我们的 处理器在等待完成 I2C 读取的过程中继续保持线路。  此时、 TPS25750 停止参与、最后一个字节在我们的处理器和逻辑分析仪上都看到为0xFF：

处理器在字节间引入的延迟并不理想、但我希望     一旦处理器最终驱动最后9个时钟周期、TPS25750就会返回0x48、而不是0xFF。 这意味着 TPS25750 经历了某种复位条件、这又引出了我的下一个问题：

[3] 我过去使用的一些器件包括 I2C 看门狗、如果时钟在启动和停止条件之间空闲时间过长、该看门狗会在内部复位器件； TPS25750是否有 包含类似功能的可能？

回答您的问题：

Unknown 说：

当您的 MCU 读取 MODE 寄存器时、TPS25750在任何时候都失去了电源(通过 VIN_3V3或 VBUS)？

这是一个很好的问题—我需要进一步拆卸 RMA 以获得这些信号的访问权限、因此我一直在避免这一步骤、以免干扰它的原始状态。 进行回答 [3] 下一个,我可以尝试这个。

再次感谢您的持续支持-如果我能澄清我的任何观察结果、请告诉我。

尊敬的 Jeff：  

Unknown 说：

我过去使用的一些器件包括一个 I2C 看门狗、如果启动和停止条件之间时钟空闲时间过长、该看门狗可在内部复位器件； TPS25750是否有机会 包含类似功能？

我们在 TPS25750中有一个看门狗计时器、让我来深入探究具体细节。  

在我的最后、您的解释/观察很清楚、一旦我了解有关 TPS25750误差恢复/计时器 I2Cs 线路上的更多详细信息、我将与您联系。  

谢谢。此致、

Raymond Lin

尊敬的 Jeff：  

TPS25750在其 I2Cs 引脚上的 I2C 超时设置为大约175ms、但如果 TPS25750将时钟线保持为低电平、而不是相反、则此设置适用。 由于处理器在中途停止读取该模式、因此可能需要 TPS25750清除 I2C 缓冲器并将其清除。 我们仍在探究该特定临界情况的具体细节。

谢谢。此致、

Raymond Lin

你好  Raymond—新年快乐！ 感谢您发送编修。

尊敬的  Raymond：感谢您的更新。 请原谅我、但我还有几个问题、只是为了确保我们确实找到了根本原因：

[1]  我报告的值(0xFF)是否代表 由于 175ms 超时而清除其出站数据缓冲区的 TPS25750？ 如果仅仅清除了缓冲区、我本来希望 TPS25750会主动驱动0x00。

由于开漏总线的性质、无法判断 TPS25750是否打算发送 0xFF、还是只是在确认地址字节后立即无响应。

[2] 这种现象在 停顿时间低至25ms 时发生；显著低于175ms。 是否存在任何超时可能在175ms 之间变化的情况？ 它可能在 PTCH 模式下较低、然后 在 APP 模式下被更新的补丁捆绑包覆盖？

再次感谢您的持续支持-如果我可以澄清我的任何一个问题、请告诉我。

尊敬的 Jeff：  

我需要再次向团队核实、看看这种情况下缓冲区通常是填充0xFF 还是0x00。 如果发生超时或发生其他情况、缓冲区中可能只填充随机数据。  

175ms 超时适用于 APP 模式、对于 PTCH 模式、我需要仔细检查并查看超时是否发生变化。  

谢谢。此致、
Raymond Lin

尊敬的  Raymond：再次感谢您的持续支持！ 期待您的反馈。

与此同时、我已经执行了一个权变措施、 在返回一个或多个意外字节的情况下、将多次重试读取 MODE 寄存器。 经过数天的连续测试、问题再次出现；我很高兴地报告、第二次读取(字节间没有延迟)成功完成。

我想最后一步是确认 TPS25750看门狗的特性与我的观察结果相符；然后我们可以关闭该线程。 如果我能提供任何其他信息、请告知我。