“Thread: Test, INA3221”中讨论的其它部件
大家好,团队
我的客户使用我们的 TMP112A。
在读取 TMP112 0x03寄存器的过程中,SCL 继续被向下拉约25毫秒,然后返回异常值0xff。 具体波形如下所示,请帮助分析可能有什么问题?
触发器超时是否导致此问题? 但超时的典型值是30毫秒。
此致,
刘德华
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.
大家好,团队
我的客户使用我们的 TMP112A。
在读取 TMP112 0x03寄存器的过程中,SCL 继续被向下拉约25毫秒,然后返回异常值0xff。 具体波形如下所示,请帮助分析可能有什么问题?
触发器超时是否导致此问题? 但超时的典型值是30毫秒。
此致,
刘德华
你好,拉科斯特,
是的,客户测试不同的主板,并看到相同的行为;
SCL 持续被按下的原因是该程序允许中断时钟在这段时间内切换以执行其他操作,然后在完成后切换回;该程序是第三方模块,因此客户无法直接修改它。 关键问题是该程序有缺陷;
但客户希望确定这是否会导致超时,以便他们和最终客户能够评估风险;
注意两个问题:
1.不同主板的 SCL 下拉时间将在25~27毫秒之间变化1~2ms。 因此,我们有相关的测试数据来阐明超时触发的最短 SCL 下拉时间?
2.当 SCL 被拉低然后被拉高时,它将返回两个字节,并且从一开始就会出现错误,例如我在开头发送的波形; 有时,在尝试返回第一个字节(设备地址)后,第二个字节的某个位会出现错误。 这是否符合超时规则? 同时,SCL 被拉低以触发超时现象。
请帮我检查,谢谢拉科斯特。
此致,
刘德华
你好,拉科斯特,
我的客户还测试了 INA3221进行比较;
我发现 INA3221技术指标提到超时28~35mS;客户拉下 SCL 大约199ms,INA3221也可以返回正确的值,如下面,他们读取了 INA3221(0x41) 0x00寄存器,然后 SCL 向下拉199ms,然后释放并返回正确的值0x71 0x27。
TMP112和 INA3221的超时机制是否相同? 为什么结果不同,请帮助回答“谢谢”。