您好!
我们使用 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 模式下、其他子命令似乎运行良好。
您认为这可能是芯片方面的问题吗?
此致、
巴蒂斯特。