您好！
我们使用 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 模式下、其他子命令似乎运行良好。
您认为这可能是芯片方面的问题吗？
此致、
巴蒂斯特。
您好！
在使用器件之后、我们似乎发现了错误来源。
我们的方法当前发送一个传输帧"0x3E 0xA0 0x00"、然后开始在循环中读取以检查0x3E、直到没有0xFF 回读。
我们当前不会在每次轮询时发送发送"0x3E"帧来指定要读取的寄存器。
这适用于其他命令、因为"0x3E"似乎保留在存储器中、因此当要求读取时、器件始终在该地址发回数据。
但与 OTP 相关的命令似乎需要更多的执行时间(这是正常的吗？) 这个技巧不起作用；"0x3E"似乎丢失了。
因此、通过在每次轮询时指定"0x3E"地址、我们可以从器件获取预期数据。 现在一切都更加一致、因为从"0x3E"中读回的数据也与发送的命令相匹配。
如果 OTP 命令有任何用途、我将附加无法使用的方法的屏幕截图。
顺便说一下、芯片上接受的电压似乎介于8.3V 和10.3V 之间、而不是10-12V 之间(我们的电源与从寄存器读取的值相匹配)。
希望这可以帮助他人、
巴蒂斯特。
帧起始(仅0xFF 读取)：
