[参考译文] TMP118：NIST ID 读取不正确（唯一 ID）。

您好 Ben、

您能否为我们提供交易前后发生的所有事情的示波器截图？ 我将进一步调查此事、并尝试在我这边复制它

仪表

仪表、

感谢您的调查。

既然之前+ NIST 读取+之后需要显示大量数据、逻辑分析仪的跟踪是否可以接受？  在示波器屏幕上获取这么多数据将是... 具有挑战性。

我可以提供 Sigrok/Pulseview 会话文件或 OpenBench 格式文件。

仪表、

此外、如果您有兴趣、这是 I2C 信号的放大视图。  信号完整性看起来非常好、因此我几乎完全排除了这是可能的原因。

仪表、

这是一个 Pulseview/Sigrok 会话文件、它包含了多次重复的读取序列。  我尚未在逻辑分析仪上成功捕获“错误读取“、但这会显示事件顺序。

Ben

e2e.ti.com/.../TMP118_5F00_Read_5F00_Example.zip

Ben、

查看会话文件提出的问题。 您是否知道在复位 CONFIG 寄存器后的周期中的第一次或第二次读取时发生了错误读取？ 如果它发生在设置 CONFIG 寄存器后的第一次读取时、则可能是在设置 CONFIG 寄存器和转换的同时设置 CONFIG 寄存器的情况。 如果没有延迟、这可能会导致 NIST ID 寄存器出错。 这是 其中一位设计人员的主导理论、建议在设置 CONFIG 寄存器后添加 12ms 的等待时间。

要正确确定这是否是问题、您需要能够在错误读取期间捕获器件的电流。 如果该值为高电平、我们可以假设在 CONFIG 寄存器组和 NIST 寄存器读取的同时发生了转换、这可能导致这些寄存器不正确。  

当然、如果您发现在器件已经处于关断模式时发生错误读取（设置 CONFIG 寄存器后进行第二次读取、或设置后 12ms）、我们需要进一步研究这一点。 请向我更新您的调查结果。

仪表

仪表、

双读是我添加的尝试和解决问题的东西。

基本上,我读取 ID 两次,确认两次都是相同的,0x0C ！= 0x0D ！= 0x0E

如果这些情况中的任何一个不真实、请再次执行双精度读取序列。

这似乎解决了问题。  根据我所见，我认为我同意设计人员的观点 — 如果传感器恰好处于转换过程的中间（或在中的某个时刻）、则可能无法正确响应。

遗憾的是、我没有办法查看这些传感器的电力线数据来仅测量这些传感器的电流消耗、因此执行该测试将很困难。

我想我将继续执行这一缓解策略。

了解 NIST ID 是否有任何“规则“会更有帮助。  例如是否允许使用 0x0000's？  0xFFFF 如何？

基本上、我试图提出一种可以确认“良好读取“的算法。

目前,我的规则如下:

• 0x0C！= 0x0D！= 0x0E
• ((0x0C！= 0x0000)&&(0x0D！= 0x0000)&&(0x0E！= 0x0000))
• ((0x0C！= 0xFFFF)&&(0x0D！= 0xFFFF)&&(0x0E！= 0xFFFF))
• FIRST_READ = second_read
  

你能建议任何额外的护栏吗?

我试图避免添加静态延迟、因为这个问题在极少数情况下会出现。  在这个项目中、我检测到 256 个传感器的数组、因此每个传感器加上 12ms 开始成为“实际时间“（3 秒以上）。

Ben

Ben、

就有效的 NIST ID 而言、我认为这是将其中任何一个值识别为“错误读取“的有效方法。

如果器件仍处于连续转换模式而不是关断模式、或者您没有发送您当前发送的 0x0000 这些虚拟字节、则器件将以 0x0000 进行响应。 这使得器件有足够的时间使用正确的寄存器值进行响应。 另一方面、如果该地址发送 NACK、它将以 0xFFFF 进行响应。

至于额外的防护轨、可能值得检查是否没有两个器件提供相同的 NIST ID、以验证在某些时候是否也存在 I2C 通信问题。 这不应该是一个问题,但它值得做,以防万一.

对于处理 12ms 等待时间、我理解这是不方便的。 但是、我建议您不要尝试执行一条关断命令->等待时间-> NIST 读取->下一个器件的模式、而是节省执行以下操作的时间。 将系统中的每个设备置于关机状态、然后在首次完成 12ms 等待时间后、继续扫描所有 NIST ID。 这将显著减少总等待时间、我们可以确保转换不会导致此错误。

仪表