Error while setting the ST25DV64KC NFC password

[GLeon.4]

Hello

We are currently using ST25DV64KC nfc-v tags in our products, and found a possible bug during production.

We set the NFC password in the last production step, using a self-developed android app (as, to my uderstanding, it cannot be done via i2C), via the 0xB1 command. 

transceive( 0x02,0xB1,0x02, password_slot,8_bytes_password )

Most of the time everything works, but there have been some occurences where the java transceive command failed, launching an exception. When this happens, upon inspection, the tag behaves as like badly programmed with an unknown password!!!

To my understanding, this should not be possible, as your protocol tranfers the password twice to avoid exactly this... and when this happens, the device is bricked as the RF pwd cannot be reset via I2C

Details from testing:

• This happens alot more with some phones. During testing,  A Pixel 6a needed hundred of password writes before the password broke, while a Samsung A54 can almost surefire break it in a handful of tries
• Testing was done on both powered off (energy harvesting) and  powered-on via vcc tags. In the latter, seems like the error incidence is lower, but still very possible.
• Reproduction of the bug was done by suddenly removing the phone while programming, and by sliding it parallel to the tag trying to edge the RF field.

Do you have any experience with this problem, and is there a way to limit the incidence? We develop our own tools and firmware, so is there anything we can do?

[JL. Lebon · Accepted solution]

Hello, 

Password are stored into the EEPROM memory of the tag. EEPROM memory are read fast, but require a write cycle to be written, which is kind of slow. A write cycle is an erase of an EEPROM cell followed by the write of the new value in this cell.
When writing a password, you are programming 8-Bytes of EEPROM. This operation takes ~10ms (erase + programming of the EEPROM). The write cycle is starting at reception of the End Of Frame of the RF request and is finished at the Start Of Frame of the RF response.
During the ~10ms write cycle, it is crucial that the RF field is stable in order to maintain power on internal programing circuitry (internal circuitry is powered by RF field, not by VCC when writing from RF). If the RF field becomes too low to power the tag during the write, the content of the EEPROM can be corrupted as the write cycle is stopped during erase or during programming. This is true for writing password, but this is also true when writing any data into the EEPROM using the Write Single/Multiple Block or any other command that writes into EEPROM.

The fact that the password is sent twice has nothing to do with programing, it is just a confirmation that you provided the correct value. The two values are internally compared and then only written into the EEPROM.

In your case, I suspect that the RF field is not stable enough. As the operation is quite long (~10ms) it is possible that a slight movement with the phone misalign the antennas reducing the RF field power below the minimum limit. Some phones have very small antenna, or antennas placed in un-practical places (specially the Samsung ones) and it is easy to misalign the antennas.

I strongly recommend not to do a production programming using a smartphone but rather a professional RF reader. Those have more power and larger antennas, which gives more stability to the RF field. 
If smartphone must be used, I recommend having it mechanically fixed to a position when updating the password.

Hope this helps.
Best regards.