RF communication blocked if write to EEPROM fails

[BRonc.1]

I use a ST25DV on my board, which communicates through I2C to a uC and through NFC with a smartphone, app developped with Flutter for Android and iOS. Everything works correctly, but sometimes, when I'm writing from Smartphone to ST25DV EEPROM and the tag is lost, the RF communications is disabled; my app (but also native ST25 app) is not able to detect tag, I must restart my device to see it back to work. During this condition, the I2C bus works correctly and also if I re-initialize the ST25DV, the RF remains blocked. Is there a way to understand why and/or a turnaround to solve the problem?

[BRonc.1]

Hi Lebon,

I've to write from a smartphone the configuration of our device, which is 224bytes long; so we have to do 14 transmission of 16 bytes each, and the procedure is very simple:

• When the smartphone feel the tag, the transmission begins.
• When a (correct) full write to EEPROM is completed, the GPO pin gives an interrupt to our uC
• The uC disable RF, manage the data received and re-enable RF
• When the smartphone feel again the tag, the procedure is complete

Please note that the

• uC disable RF only AFTER the reception of the interrupt and then re-enable it
• The procedure works well 99% of times
• It is hard to reproduct the problem, we have to do lots of tries
• When the RF has an unwanted block, the uC has NOT received the interrupt of end of write, beacuse the tag is loss before, so it is not the uC which disable RF, I'm sure of it.
• From the smartphone logs, it seems the block appears only when the tag is lost during the last trasmission, but I have to double check it.

The 3rd byte of UID is 0x26 (ST25DV16K-I).

[JL. Lebon]

Hello,

Thank you for the complete explanation.

• The uC disable RF, manage the data received and re-enable RF

I guess the uC disables the RF by writing RF_MNGT_Dyn=0x02 ? and re-enables it by writing RF_MNGT_Dyn=0x00 ?

Would it be possible that the I2C command to re-enable RF fails without being detected by your software ? If you have the possibility to make a trace of the I2C transactions (and GPO pin) until it fails with a logic analyzer, it may help to understand what's going on.

Best regards.

[BRonc.1]

Hi Lebon,

you're right, I set RF_MNGT_Dyn to enable/disable RF.

I'm pretty sure the uC doesn't execute this part during block because the GPO interrupt is not received, and if I force the uC to re-initialize the IC, RF doesn't work until a hard reset (unpower and repower). I've checked thought debug messages but also with an oscilloscope.

[BRonc.1]

This is the registers status after a RF block, first element is address, second is value.

I hope this could help.

[JL. Lebon]

Hello again,

From what I see on the registers dump, you have ST25DV16K revision 1.2 (this is the address 0x20).

The revision 1.2 has been obsoleted and replaced with the revision 1.3.

For information, some improvements have been made in cut 1.3, mainly on robustness to tearing.

I'm pretty sure that what you experience is some weakness to tearing during RF write. In the revision 1.2, in specific conditions, tearing can lead to blocked communication on the RF side. In your case, it probably happens when the smartphone is moved a little bit too far from the tag, that's why you don't see it happening very frequently.

Revision 1.2 of the ST25DV16K has been replaced by the revision 1.3 during 2020, so you probably got an old stock or get it a long time ago.

(you can also see the revision of the device on the marking, please see https://www.st.com/content/st_com/en/st25-marking-information.html. Marking ending with a A is revision 1.2, and B is revision 1.3)

I strongly suggest that you get your hands on a revision 1.3, or even better, to switch to the newest ST25DV16KC, which is a more recent and improved version ST25DV16K (this is the device recommended by ST for new designs as the ST25DV is noted NRND (not recommended for new design)).

Best regards.

[BRonc.1]

Hi JL,

good to known... I've check our production and we have only revB IC, we have in our lab some samples with revA. I will do more tests with revB onboard. By the way, I can drive ST25DVKC the same way as ST25DVK or I have to do some porting hw or sw?

[JL. Lebon · Accepted solution]

Hello,

Good that your production is only revB. Please replace your revA sample in the lab and test again with revB. Problem should not show again.

Concerning ST25DVKC, there is no HW modification to do when coming from ST25DVK. On SW side, some adaptation must be done but are very limited. There is an application note explaining in detail the difference between the K and KC version that should help: https://www.st.com/resource/en/application_note/an5633-migrating-from-st25dvxxk-to-st25dvxxkc-stmicroelectronics.pdf

Best regards.