Hi,
We are using I2C default config (400kHz), and communicating via a host µC.
We are having some issues with the OTP_WR_CHECK subcommand (0x00A0).
When calling this command outside CFGUPDATE mode, it works well (returns locked state, as expected).
When calling this command once we are in CFGUPDATE mode, things get tricky.
Here is how our method works (and seems to be functional with other subcommands) :
Write the command (here 0x00A0) at address 0x3E. Endianness is respected.
Read (on loop) at address 0x3E until the device stops returning 0xFF.
Read at address 0x40 for data.
When sending command 0x00A0, the device takes about 10ms (long time) to stop answering 0xFF at a 0x3E read.
The data sent back from address 0x3E is 0x00 (if it can help).
The data read back from address 0x40 is 0xFF for the 3 bytes (problem).
Now for testing purposes we tried changing the condition for data read back:
Instead of reading 0x3E until it stops returning 0xFF, we read 0x3E until it returns the original command (0xA0).
In that case, it takes about 100ms to verify the condition (consistent time), and we can see various data read back from 0x3E until we see the 0xA0 come back.
Doing it this way we can actually get OTP_WR_CHECK values, but it doesn’t work at every BAT voltage (weird).
Some voltages make the chip never return the 0xA0 command in 0x3E register.
Again, other subcommands seem to be working well, while in CFGUPDATE mode or not.
Do you think it could be an issue on the chip side ?
Best regards,
Baptiste.
