Skip to main content
Associate II
September 1, 2023
Solved

Reading of ST25DV returns NACK via I2C

  • September 1, 2023
  • 4 replies
  • 2095 views

Hello, i'm starting to work with a ST25DV64 device and at beginning the read command of UID (Address 0x0018) just work fine. And i get the UID of the chip.
But after implement some write commands (password,fast transfer mode, enable gpo,...) the chip now only return NACK after reading the UID. I removed all other commands, but reading of UID only return NACK.

What happens to the chip? Is he locked? And how can i get him unlocked? Or is maybe the chip deadlocked?

We are testing with the ST board ANT7-T-ST25DV64KC and we put some pull-up resistors with 10k.

I have now 3 boards that are all "locked".
  

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

Hello dierdorf, 

I suspect that you may have accidentally changed the I2C slave address of the ST25DV64KC.

Actually, there are two versions of the ST25DV: ST25DVxxK and ST25DVxxKC versions. The two are very close, but there are some small differences in configuration addresses.

For instance, in ST25DVxxK, the MB_WDG configuration byte is in address 0x000E, whereas in ST25DVxxKC it in 0x000D. In ST25DVxxKC, the configuration address 0x000E is the I2C slave address. (see https://www.st.com/resource/en/application_note/an5916-minimal-migration-path-from-st25dvxxk-to-st25dvxxkc-stmicroelectronics.pdf)

So, if you configured your tag for Fast transfer Mode and wrote the MB_WDG configuration at address of the ST25DVxxK, you may have accidentally changed the slave address of your ST25DVxxKC.
Can you please check this?

Best regards.

4 replies

JL. Lebon
JL. LebonBest answer
ST Employee
September 5, 2023

Hello dierdorf, 

I suspect that you may have accidentally changed the I2C slave address of the ST25DV64KC.

Actually, there are two versions of the ST25DV: ST25DVxxK and ST25DVxxKC versions. The two are very close, but there are some small differences in configuration addresses.

For instance, in ST25DVxxK, the MB_WDG configuration byte is in address 0x000E, whereas in ST25DVxxKC it in 0x000D. In ST25DVxxKC, the configuration address 0x000E is the I2C slave address. (see https://www.st.com/resource/en/application_note/an5916-minimal-migration-path-from-st25dvxxk-to-st25dvxxkc-stmicroelectronics.pdf)

So, if you configured your tag for Fast transfer Mode and wrote the MB_WDG configuration at address of the ST25DVxxK, you may have accidentally changed the slave address of your ST25DVxxKC.
Can you please check this?

Best regards.

dierdorfAuthor
Associate II
September 5, 2023

Thank you very much! 

It's unbelievable that a new derivate change has so strong impact to the functionality.

Are there a way to recover the slave address via I2C or RF?

We are very happy that we now know, why our modules cancel the I2C communication.

Best regards

JL. Lebon
ST Employee
September 6, 2023

Hi, 

To recover from that, what you need to know is the new I2C address that is programmed into the ST25DVxxKC. For this, there are 2 solutions:

- The easiest one is to look into your code and see what you have write at address 0x000E. This address was MB_WDG in the St25DVxxK, so if you know what you set for MB_WDG (watchdog for FTM), then you can find what is your new I2C address (I2C address setting is explained in chapter 6.3 in the St25DVxxKC datasheet).

- The second solution is to "scan" devices from I2C. You need to add to your code a function that will explore all I2C slave addresses (there are only 128) and see when the address is acked.

In any case, once you know your new I2C address, you need to reprogram it from I2C interface (this is not possible from RF interface). The effect of programming address 0x000E is immediate, meaning the next I2C command will have to use the new I2C address.

Best regards.