- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
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.
Hello,
After playing around with the device, it seems that we found the source of error.
Our method currently sends a transmit frame "0x3E 0xA0 0x00" and then starts reading on loop to check 0x3E until there is no 0xFF read back.
We currently do not send a transmit "0x3E" frame on every poll to specify the register to be read.
This works with other commands because it seems that the "0x3E" is kept in memory, thus the device always sends back data at this address when asked for a read.
But the OTP related commands seem to take way more time to execute (is it normal ?) and this trick doesn't work then; "0x3E" seems to be lost.
So, by specifying the "0x3E" address on every poll, we can get the expected data from the device. Everything is now more coherent, as the data read back from "0x3E" also matches the sent command.
I'm attaching screenshots of the method that doesn't work with the OTP commands, if it is of any use.
By the way, the accepted voltages on the chip seem to be between 8.3V and 10.3V instead of 10-12V (our supply is matching the values read from the registers).
Hoping this can help someone,
Baptiste.
frame start (followed by only 0xFF reads):
