主题中讨论的其他器件: ISOW7841、 ISO7731、 BOOST-PSEMTHR-007、 TPS23881
在我们的器件中、某些寄存器的值由 Linux POE 守护程序定期从 TPS23880 POE 控制器中读取。 少量读取事务会返回意外的寄存器值。 根据测试实验、我们发现意外值是中断寄存器(00h)的内容。 例如- POE 守护程序读取温度寄存器(2Ch)、但读取的值是中断寄存器(00h)的内容。
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
在我们的器件中、某些寄存器的值由 Linux POE 守护程序定期从 TPS23880 POE 控制器中读取。 少量读取事务会返回意外的寄存器值。 根据测试实验、我们发现意外值是中断寄存器(00h)的内容。 例如- POE 守护程序读取温度寄存器(2Ch)、但读取的值是中断寄存器(00h)的内容。
您好、达尔文、
测试 是在我们自己的电路板上进行的。 在实验过程中、验证了电隔离层两侧的信号完整性。 同时 、示波器对通信进行解码、以消除软件中出现误解的可能性。 理论上、我们可以尝试使用 EVM 复制实验、 但目前我的 SW 部门同事正在休假、因此我必须等待他返回工作岗位。 但是、我们确信通信清晰、不会受到干扰、并且在 I2C 事务级别上不符合预期。
为了解释我们是如何发现问题的- 在测试设备时、我们观察到偶尔从电流测量寄存器中读出的值过低。 首先、我们测试了所测试的 POE 器件上是否存在电流下降。 当我们验证 POE 器件的电源是不间断且稳定的时、我们重点关注与 POE 控制器的通信。 经过多次实验、我们观察到、读取寄存器时的意外值与中断寄存器中当前的值相对应。 另一项调查结果是,有些登记册比其他登记册更容易受到这种误解。
您好、Jiri、
感谢更新、查看 EVM 是否也表现出这种行为将会很有趣。 如果您无法在 EVM 上进行复制、有几条评论吸引了我对原理图的注意、1.5k Ω 上拉电阻看起来很低、我通常看到5k 电阻。 此外、ISOW7841建议的最小电压为3V。 这非常接近3.3V 电压轨、而我们使用的是 ISO7731、它具有2.25V 的最小建议电压、并为3.3V 电压轨提供足够的裕量。
如果您认为 EVM 工作正常、这些注释可能有助于进行调试。 这是我可以指出的主要硬件差异。
感谢您解锁线程。
我们能够再现使用带有子板 TPS23880EVM-008的评估模块 BOOST-PSEMTHR-007所描述的问题。
该 EVM 通过 USB 接口适配器(J2)连接到器件的 I2C 总线、子板已将 I2C 地址设置为20h。
我们使用 I2C 寄存器访问配置 A (8位访问)。
我们能够以最快的方式重现行为的测试案例:
我们打开 EVM、通过 I2C 写入以下寄存器、通过诊断/手动模式打开所有 PoE 通道:
地址20h:
运行模式寄存器(12h)值55h
断开使能寄存器(13h)值00h
功率优先级/2P-PCUT 禁用寄存器(15h)值0Fh
2x 折返选择寄存器(40h)值 F0h
电源使能寄存器(19h)值0Fh
地址21h 也是如此。
然后、我们在器件中运行代码、该代码从无限循环中的 I2C 地址20h 读取器件 ID 寄存器(43h)、并检查其值是否为0010、0001b (21h)。
大多数读取的值检查都正常、但大约10分钟后、我们读取了83h。 在10分钟内、我们执行大约50000个读取周期。
我们假设值83h 与中断寄存器(00h)的内容相对应-它在 PoE 通道开启后包含83h、当我们通过读取相应的事件寄存器清除某些位时、我们使用读取循环读取该值。
为了更快地重现问题、所有 PoE 通道都需要打开、我们读取器件 ID 寄存器、我们只需检查该寄存器、问题就会在最短的时间内出现。
尊敬的 Penny:
我的同事 Ales 在1月3日之前不在办公室 但 我将尝试回答您的一些问题。
检索意外值仅限于单次读取。 预期值0x21已在下一个读取周期中返回。 ID 寄存器的错误率约为1/500k 次读取。
问题不限于 ID 寄存器。 读取器件 ID 寄存 器只是引起故障读取的最简单方法(因为我们知道要读取的值)。 但最初我们通过读取 电流测量寄存 器发现了该误差、当时我们的测试软件报告了 POE 负载上的电流下降。 根据测量结果和后续分析 、我们发现负载上的电流和电压稳定、 问题是从寄存器中读取错误值导致的。 在这些测量期间、我们在独立器件上捕获了 I2C 通信。 在通信分析过程中、μ Aleš 发现异常值与中断寄存器的当前值相关。 我想他说过,不同的登记册读数失败 ,概率也不同。 换言之,有些登记册比其他登记册更经常失败。
谢谢、祝您愉快
尊敬的 Penny:
您的问题有解答:
-寄存器恢复:
正如 Jiri 所写的那样、在重现此问题后、0x43寄存器在下一次读取中恢复到默认值0x21。 问题是、平均周期为500k 次读取。
-寄存器0x41的值:
对于寄存器0x41、我们观察到了同样的问题-默认值为0x00、在几百次读取后、我们读取值0x83一次、寄存器在下一次读取中恢复到默认值0x00。
-来自寄存器0x06、0x08、0x0A 的故障:
对于寄存器0x06、0x08、我们观察到与寄存器0x43和0x41相同的问题-在对预期值进行数十万次读取后读取值0x83一次。
对于寄存器0x0A、我们也观察到了这个问题、因为该寄存器是读取错误值的周期、甚至更短-我们观察到在几千次读取后读取值0x83一次。
我们检查了更多的寄存器、没有观察到寄存器0x1B 的值发生变化-我们读取了正确的默认值0x55
500多万次读取。
我们在读取和使用寄存器0x0A 尝试之间增加了100ms 的延迟、该延迟周期较短-问题仍然可以重现
在几千次读取后具有一次类似的速率(仅测试运行时间更长)。
谢谢、祝您愉快。
您好、阿尔斯、
您好像没有将 SRAM 代码加载到 TPS23880中。 您能否尝试将 SRAM 代码加载到 TPS23880并查看问题是否仍然存在? 您可以访问 TPS23880产品文件夹 并请求访问 SRAM 代码。 请按照 此应用手册 和 参考代码 加载 SRAM 代码。 谢谢。
尊敬的 Penny:
我将 SRAM 代码加载到 TPS23880中、现在寄存器0x41的值为0x02、并执行相同的读取测试。
该问题仍然存在、但某些寄存器存在差异:
-寄存器0x43、0x41的行为相同-在几百次读取预期值后读取错误值一次。
-寄存器0x0A 的行为相同-在几千次读取预期值后读取错误值一次。
-对于寄存器0x06和0x08、我没有观察到改变的值。
谢谢、祝您愉快。
尊敬的 Penny:
我们发现错误的值与寄存器0x00的值相对应-在上述测试设置期间、它是值0x83、但它可以包含其他值、例如、在清除其位后、它将包含0x00、我们将读取错误的值0x00。
我添加了对具有电流(0x30)和电压(0x32)的2字节寄存器的检查、并且我观察到了与寄存器0x43和0x41相同的问题-在几百次读取后、有一个字节发生了变化、例如、寄存器0x30的值为0x0000、 值0x0083错误、寄存器0x32的值0x3803错误、值0x3883错误。
可能会使用基于另一个读取的权变措施、但在这种情况下会更复杂。
是否可以在您的设施中重现此问题?
谢谢、祝您愉快。