ST25DV04KC - how to read NDEF Text from I2C?

[dzuy]

We're evaluating the ST25DV04KC for our application. We want to write to the ST25DV04KC from NFC and read the info from I2C from our MCU.

We're able to use NFC app on the smart phone to write an NDEF Text of "12345". We can read it via NFC. But reading from the EEPROM proves to be more difficult that other I2C EEPROM. Reading the data sheet, there seems to be 2 I2C addresses, 0x53 and 0x57. We've to read from both but got 0xff for every byte.

So, our NDEF Text of "12345" is written somewhere in this chip. How do we get it out of this chip from our MCU?

[JL. Lebon]

Hello, 

The ST25DV04KC has indeed two different I2C slave addresses:
0x57 is to access the System memory
0x53 is to access the User memory.

System memory is for configuration. This is where you can set different configuration bits set to change the tag behavior.

User memory is the 4 kbits EEPROM where your data is stored. This is where the NDEF file is stored, and this is the one you want to read.

So to read the NDEF file, you must use the 0x57 I2C address.

To form your I2C command, you need to pass also the memory address as the first 2 Bytes after the I2C address, This is the address of the Bytes you want to read inside the user memory. It is coded on 2 Bytes (MSB Byte first). The memory address is set using an I2C write. Then, when the address is set, you need to issue the I2C read address to read the Bytes. The total I2C command looks like this:

START / 0x53+Write bit (0xA6) / ACK / MSB Byte of the memory address / ACK / LSB Byte of the memory address / ACK / reSTART / 0x53+Read bit (0xA7) / ACK / Data Byte / ACK / Data Byte ..... / NACK / STOP

(please see Figure 35 in the datasheet).

About the memory address:
Your NDEF data is stored after the CC File into the User memory. The CCFile is 4Bytes long for the ST25DV04KC and always starts at memory address 0x0000. So it means that your NDEF file will start at memory address 0x0004. Then you have some NDEF header and then your "12345" data.

Best regards.

[dzuy]

From our MCU's I2C api, we were able to read NDEF Text record by writing to 0x53 with 2 bytes ([0x00, 0x0a]) and read  bytes from 0x53. Thank you.

Now, we also want to use the ST25DV04KC EEPROM to reserve our board's settings. We don't need much, 8 bytes should do. If we write to 0x53, we would overwrite the NDEF record. Ideally, we'd like to allocate a certain block of memory in the EEPROM, away from the NDEF records. So our next question is, where does the NDEF records end in EEPROM memory, and where can we allocate the next block of memory after NDEF?

[JL. Lebon]

Hello, 

There is no "standard size" for the NDEF file. You can set the size you want.
The NDEF size is defined into the CC File. Please refer to this application note to understand the CC File settings: https://www.st.com/resource/en/application_note/an4911-ndef-management-with-st25dvi2c-series-and-st25tv16k-and-st25tv64k-products-stmicroelectronics.pdf.
Typically, for your ST25DV04KC, you will have to change the MLEN value which is at memory address 0x0002 (I2C memory address. In RF, it is in block 0). By default, the MLEN value is probably set to use the full memory. you can reduce it to the value you need for your NDEF file. When a reader or a smartphone wants to access the NDEF file, it first reads the CCFile and check the MLEN to know the maximum size of the NDEF.

Then, the rest of the memory is free for your other data.
If you want to be sure that your other data will not be overwritten, you can create two different memory "areas": one for the NDEF file, and one for your private data. Then, you can write protect your second area where your private data is stored, to be sure that it will never be overwritten. Creating areas is done using the ENDA1, ENDA2, ENDA3 configuration bytes. Then protecting them from RF access is done using the RFA1SS, RFA2SS and RFA3SS configuration Bytes. Please refer to those posts for more detail: 

Solved: Re: How to stop overwriting on NFC Tag of ST25DV64... - STMicroelectronics Community

Solved: Re: Secure st25dv04k from RF write - STMicroelectronics Community

Best regards.

[dzuy]

So if we set MLEN to half (20 instead of 40), NDEF will write up to 256 (512/2) and we have the rest 256 bytes for I2C without using password?

In our application, the phone app will be the first to access the tag, so our phone app will have to change MLEN, then write the NDEF Text. Then the board it powered up, reads NDEF Text, and just I2C writes wo the lower half of the user memory without using password?

[JL. Lebon]

Hello, 

If you code MLEN=20, it means that the NDEF will not exceed 0x20*8=256 Bytes long. This means that CCFile + NDEF will occupy the first 258 Bytes of the memory.

But be aware that this MLEN is only an information used by the phone/rf reader when reading or writing the NDEF file. Nothing prevents an application to write after those 256 Bytes. If you want to be sure that RF will never overwrite your I2C data, I suggest to create at least two areas in the user memory. A first area of at least the size of your CCFile+NDEF and a second area for your I2C data. Then you can protect your second area to prevent any write from RF (and you don't have to use the apssword on I2C side: protection for RF access and I2C access are different settings).

Concerning the write of MLEN, it has to be done once only. You can even do it from I2C if you want.

Best regards.

[dzuy]

Ok, we tried a simple read/write from RF and I2C.

First, as mentioned previously, our phone app writes NDEF Text "12345" from the phone app.

We're able to read this NDEF Text record from I2C by writing with { 0x00, 0x0A } at 0x53 I2C address just fine.

Now, we write 9 bytes {1,2,3,4,5,6,7,8} to { 0x0, 0x80 } at 0x53 I2C address successfully.

Using ST25 App to read the entire EEPROM memory, we're able to see the NDEF Text record at 0x0A and 1,2,3,4,5,6,7,8 at 0x80.

However using the same I2C function, calling write at { 0x00, 0x80 }, but got all 0. Why doesn't this work?

[JL. Lebon]

Hello, 

"However using the same I2C function, calling write at { 0x00, 0x80 }, but got all 0. Why doesn't this work?"

Do you mean write? Write what value ? Or do you mean read at {0x00, 0x80} ?
What is exactly your I2C command ?

Best regards.

[dzuy]

Our MCU has I2C api that we call as follow:

Init I2C:

i2c_init(0x53)

Reading I2C:

i2c_write_read(*wr_buffer, wr_len, *rd_buffer,  rd_len)

which does an I2C write then read. Calling with wr_buffer[2] = { 0x00, 0x0A }, rd_buffer[8] = {}, we can see the NDEF Text in rd_buffer.

Writing I2C:

 i2c_write(*wr_buffer, wr_len)

Which does an I2C write. Calling with wr_buffer[10] = { 0x00, 0x80, ... }, we're able to write to address 0x80. Using the ST25 app to read the entire memory space, we can verify what we write appears at address 0x80, and the NDEF Text record at 0x0A.

However, when call i2c_write_read() with wr_buffer[2] = { 0x00, 0x80 }, rd_buffer[8] = {}, we get all 0 in rd_buffer.

[JL. Lebon]

Hello, 

Sorry for my late answer.
There is no difference between address 0x000A and 0x0080. So if your code is able to write then read address 0x000A, I assume it is also able to write and read address 0x0080.
But may be something prevents to write there (area protection or crossing of area border). In your I2C_write_read() function with wr_buffer[2] = {0x00, 0x80}, do you get any NACK ? or do you have only ACKs?
Can you please share the code of the I2C_write_read() function?

Best regards.