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

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

RF_MNGT_Dyn is equal to static version, 0x00

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