Skip to main content
Explorer
November 21, 2022
Solved

RF communication blocked if write to EEPROM fails

  • November 21, 2022
  • 13 replies
  • 2552 views

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?

    This topic has been closed for replies.
    Best answer by JL. Lebon

    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.

    13 replies

    BRonc.1Author
    Explorer
    November 23, 2022

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

    I hope this could help.0693W00000WJL0XQAX.png

    ST Employee
    November 23, 2022

    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.1Author
    Explorer
    November 24, 2022

    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. LebonAnswer
    ST Employee
    November 24, 2022

    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.