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.
您好!
我们使用 I2C 默认配置(400kHz)、并通过主机 µC 进行通信。
OTP_WR_CHECK 子命令(0x00A0)存在一些问题。
在 CFGUPDATE 模式之外调用此命令时、它运行良好(按预期返回锁定状态)。
当我们处于 CFGUPDATE 模式时调用此命令时、事情会变得复杂。
以下是我们的方法的工作原理(似乎可以与其他子命令一起使用):
在地址0x3E 写入命令(在这里是0x00A0)。 字节序得到尊重。
在地址0x3E 处读取(在环路上)、直到器件停止返回0xFF。
在地址0x40处读取数据。
发送命令0x00A0时、器件需要大约10ms (较长的时间)才能在读取0x3E 时停止应答0xFF。
从地址0x3E 发回的数据为0x00 (如果它可以帮助的话)。
从地址0x40读回的3个字节的数据为0xFF (问题)。
现在、为了进行测试、我们尝试更改数据读回的条件:
我们读取0x3E、直到它返回原始命令(0xA0)、而不是读取0x3E 直到它停止返回0xFF。
在这种情况下、需要大约100ms 来验证条件(一致时间)、我们可以看到从0x3E 读回的各种数据、直到我们看到0xA0返回。
这样做实际上可以获得 OTP_WR_CHECK 值、但在每个 BAT 电压下不起作用(奇怪的)。
某些电压使得芯片永远不会返回0x3E 寄存器中的0xA0命令。
同样、在 CFGUPDATE 模式下、其他子命令似乎运行良好。
您认为这可能是芯片方面的问题吗?
此致、
巴蒂斯特。
Baptiste、您好!
是的、对0x00A0的响应取决于电压以及编程是否成功。 请参阅技术参考手册表3-1。
您似乎在该帖子中获得了有关此问题的帮助。 如果您仍有疑问、请告知我们。 https://e2e.ti.com/support/power-management/f/196/p/953104/3522768
您好!
抱歉、这是另一个问题。
我们无法使命令0x00A0和0x00A1正常工作。
我们始终返回0xFF 作为答案、并且这是经过很长时间后的结果。
所有其他命令和子命令(无论是否有数据)似乎都能正常工作。
您是否遇到过 OTP 命令发回0xFF 的问题?
根据 参考手册第122页、0xFF 应该是不可能的。
即使电压超出范围、0x00A0和0x00A1也应应答一致的内容。
我希望您能给我们启迪、
此致、
巴蒂斯特。
您好!
在使用器件之后、我们似乎发现了错误来源。
我们的方法当前发送一个传输帧"0x3E 0xA0 0x00"、然后开始在循环中读取以检查0x3E、直到没有0xFF 回读。
我们当前不会在每次轮询时发送发送"0x3E"帧来指定要读取的寄存器。
这适用于其他命令、因为"0x3E"似乎保留在存储器中、因此当要求读取时、器件始终在该地址发回数据。
但与 OTP 相关的命令似乎需要更多的执行时间(这是正常的吗?) 这个技巧不起作用;"0x3E"似乎丢失了。
因此、通过在每次轮询时指定"0x3E"地址、我们可以从器件获取预期数据。 现在一切都更加一致、因为从"0x3E"中读回的数据也与发送的命令相匹配。
如果 OTP 命令有任何用途、我将附加无法使用的方法的屏幕截图。
顺便说一下、芯片上接受的电压似乎介于8.3V 和10.3V 之间、而不是10-12V 之间(我们的电源与从寄存器读取的值相匹配)。
希望这可以帮助他人、
巴蒂斯特。
帧起始(仅0xFF 读取):