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?

[Ulysses HERNIOSUS]

Hi,

"I must restart my device to see it back to work." Which device do you need to restart? The smartphone?

BR, Ulysses

[BRonc.1]

No, the device with ST25DV onboard

[Ulysses HERNIOSUS]

Hi,

I would start checking RF_MNGT.

BR, Ulysses

[BRonc.1]

Hi Ulysses,

reading from I2C, RF_MNGT=0x00, it seems RF is enabled but it is not.

[Ulysses HERNIOSUS]

Hi,

what about the Dynamic Configuration, especially RF_MNGT_Dyn?

BR Ulysses

[BRonc.1]

RF_MNGT_Dyn is equal to static version, 0x00

[JL. Lebon]

Hello,

Not sure I understand the following statements:

"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."

In the first sentence, you say that if you restart the ST25DV, it works again, but in the second sentence you say that it remains blocked if you re-initialize it. So, what do you mean by re-initializing it ?

I can see 3 different reasons why the RF would be lost:

• ST25DV is set in RF Sleep or RF disable mode by the I2C writing in RF_MNGT_Dyn register. This would be temporary until the next boot of the ST25DV, so it can match your case.
• Energy Harvesting is set ON by the I2C writing in EH_CTRL_Dyn register and current consumption is too high and is preventing RF communication. Are you using Energy harvesting ?
• I2C is constantly busy, preventing the RF reader to access the device. You may monitor the I2C with a oscilloscope or a logic analyzer when this happens to check if I2C activity is not too high.

Best regards.

[BRonc.1]

Hi Lebon,

When RF is blocked, the uC connected through I2C to the ST25DV can send an initialization sequence to test if RF is in sleep or disabled:

• read UID,
• present password,
• set interrupt vector 0x80,
• set IT time 0x03,
• set RF sleep OFF in RF_MNGTDyn register
• read also RF_MNGT register

Each write is followed by a read to check if it is ok.

When I force the uC to send the init sequence, the RF remains blocked even if RF_MNGT and RF_MNGTDyn are eual to 0x00

If I power off my device (so the ST25DV also), RF restarts to work (I can read ST device with ST25DV app); if I re-power on my device, RF continues to work.

As a note I can say that in normal operation everything works correctly; I have the problem sometimes when the tag is lost during write in EEPROM procedure.

I don't use Energy Harvesting.

I2C bus has a low traffic.

[JL. Lebon]

Ok, thank you for the explanation of the initialization procedure.

Other questions to try to understand what's going one here:

Can you explain what your EEPROM write procedure does ? as it seems linked to this procedure.

It is 100% time reproductible when you use this write procedure ?

Can you please tell ne the exact version of St25Dv you are using ? (You can just give me the 3rd byte of the UID after the E002).

Best regards.

[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.