Issue with getting proper data payload out of ST25DV via I2C after writing to it via NFC.

[KKosi]

Lets start with what works...

I can write NDEF payload to ST25DV via I2C and read it back via I2C and using NFC Tools App.... This works fine and perfectly. I can also write NDEF messages using NFC Tools, and read back what I wrote no problem.

The exact issue comes up when I try to read what I wrote to the ST25DV tag (using NFC Tools) using NFC. I don't get garbage exactly... i do get some correct bytes out (the NDEF header is mostly correct), but the payload data portion seems corrupted. What i get from reading via I2C is repeatable...as in I read the same corrupted data with every read. If I write a new NDEF message via I2C, then the corruption no longer exists and I can read back the NDEF message that I wrote (via I2C) without issue.

NFC Tools App allows you to read the memory from the ST25DV. The memory I am reading doesn't match what I read via I2C after I write to the ST25DV using the NFC Tools App. The NFC Tools App seems to have access to a different memory then what the I2C domain does, yet the I2C domain is able to easily write into the NFC domain. This is of course an abstraction for understanding my issue.

There is nothing actually wrong with the ST25DV unit I have on the surface level. It works fine with an Arduino running on STM32L476RG using the st25dv arduino driver (github: stm32duino/ST25DV) without any issues so there as to be some sort of issue with my setup....

In my setup I am using a custom board with Muratta CMWX1ZZABZ-078 that has a STM32L072 on the SoC. The board "B-L072Z-LRWAN1" makes use of this SoC. My I2C lines have other peripherals on it such as a BME280. I can read and write to the BME280 without a problem. My project is based on ( github: Lora-net/LoRaMac-node), of which I inherited all the I2C / Clock settings / API from (building it as if it was a B-L072Z-LRWAN1). I have tried using I2C speeds of 100kHz and 400kHz.

I have an I2C logic analyser. Here's an example of successful read/write using I2C only. I make an NDEF text entry with the string "TestEntry123". Too be clear these transactions work as expected.

write to 0x53 ack data: 0x00 0x04 

read to 0x53 ack data: 0x03 0x13

write to 0x53 ack data: 0x00 0x06 

read to 0x53 ack data: 0xD1 0x01 0x0F 0x54 0x02 0x65 0x6E 0x54 0x65 0x73 0x74 0x45 0x6E 0x74 0x72 0x79 0x31 0x32 0x33

write to 0x53 ack data: 0x00 0x04 0x03 0x13 0xD1 0x01 0x0F 0x54 0x02 0x65 0x6E 0x54 0x65 0x73 0x74 0x45 0x6E 0x74 0x72 0x79 0x31 0x32 0x33 

write to 0x53 ack data: 0x00 0x04 

read to 0x53 ack data: 0x03 0x13

write to 0x53 ack data: 0x00 0x06 

read to 0x53 ack data: 0xD1 0x01 0x0F 0x54 0x02 0x65 0x6E 0x54 0x65 0x73 0x74 0x45 0x6E 0x74 0x72 0x79 0x31 0x32 0x33

The last line with the read does give me an NDEF message of "TestEntry123" as intended.

Here is the actual I2C signals... again this is the working signals. running at 100kHz.

When read from NFC Tools, 1 record is found. UTF-8 (en) : text/plain "TestEntry123"...as expected. Great that works.

If I used NFC to write the same text entry...i can read it back using I2C...but this seems to be illusion of proper function.

Now here is where my problems begin; I will use NFC Tools to write a DIFFERENT NDEF text entry, and my firmware will just read from the tag via I2C instead of writing anything. I will provide the transactions below. When I read the tag again via NFC Tools, i get the correct text entry data in the app, and when I read the raw memory from NFC Tools, everything looks good and as expected. If I write the same NDEF text message as I written with I2C previously, there is no issue.

In these transactions after I wrote "123TestEntry" via NFC Tools, I simply just read the data from the tag. Again if I just wrote "TestEntry123" (the same as what I wrote via I2C previously), I will be able to read using the same I2C requests below without issue.

write to 0x53 ack data: 0x00 0x04 

read to 0x53 ack data: 0x03 0x13

write to 0x53 ack data: 0x00 0x06 

read to 0x53 ack data: 0xD1 0x01 0x0F 0x54 0x02 0x65 0x6E 0x10 0x20 0x33 0x54 0x45 0x62 0x74 0x40 0x68 0x30 0x32 0x31

This gives me text output: "0x10 , 0x20 ,  3 , T ,  E ,  b ,  t , 0x40 ,  h ,  0 ,  2 ,  1"

This output is repeatable.

Here is the I2C signal.

Closer look at the clock.

Any help/tips on this issue would be appreciated. Let me know if there is any other kind of analysis you would like to see to help me get to the bottom of this.

[Tesla DeLorean]

@JL. Lebon_O​ 

Follow on from https://community.st.com/s/question/0D53W00001X4uTmSAJ/ant7tst25dv04k-cmwx1zzabz078-stm32l0-i2c-read-issues

[JL. Lebon]

Hello,

let me try to summarize to check I have understood correctly your issue:

1. writing NDEF_1 from I2C and then reading back from I2C => no issue
2. writing same NDEF_1 from NFC using NFC tools app and then reading back from I2C => no issue
3. writing NDEF_2 from NFC using NFC Tools app and then reading back from NFC tools app => no issue
4. writing NDEF_2 from NFC using NFC Tools app and then reading back from from I2C => garbage

Do I get it correctly ?

Point 1 let us think that I2C is working correctly.

Point 2: I2C is reading correct value, but we have no proof that NFC really write it in memory has this data was already present in memory from point 1...

Point 3: let us think that NFC is writing and reading correctly

Point 4: either NFC has not written data correctly, or I2C is not reading data correctly.

I2C is a quiet simple system and from the other post about this topic, I understood that you already checked the bus and pulls-up resistors. So I think I2C will have less chances to be the root cause. To be sure, the only way would be to put an oscilloscope on SDA/SCL lines and check if the transaction is OK where you read garbage bytes (you can trust an oscilloscope much more than a logic analyzer). With a scope you can precisely check that the timings and the voltage levels are good.

On NFC side, I don't really know what NFC Tools is doing and NFC interface is less robust than I2C since it is RF. You may have an issue with the application not really doing what it says it does. Or you may have an issue with the RF communication itself. Or both.

Can you try to write NDEF with another application, for example the ST25 NFC Tap app ?

When writing NDEF with the NFC, you can try to first write NDEF, then remove the phone from behind the tag (eventually exit the app) and then come back to the tag and read memory back ? (this is to ensure that the app is not just showing you what it has in cache and not something it really reads from the tag).

Also, I can see that the murata module is shielded. The ANT7 antenna needs to be away from the shield since the shield will block the magnetics field. For example, if the antenna is stacked on top of the murata module, it may not work properly. Is it the case ?

Best regards.

[Ulysses HERNIOSUS]

Hi KKosi,

I do have a wild idea that the issue could still be on I2C. I have seen in the past cases where I2C devices incorrectly "felt" addressed by data going/coming from other devices and started garbling data on the I2C bus.

So I would also make a trial to disconnect the other devices from the I2C bus and see if the issue persists.

Best Regards, Ulysses

[KKosi]

Yes, you have summarised my issue correctly.

The issue persists with the ST25 NFC app. I have tried closing the app and clearing the data/cache then try to read again.

Antenna shouldn't be an issue, the ST25DV is several cm away from the murata module and has air gap to enable magnetic coupling. The ST25DV is not stacked on any metal plane and magnetic fields should be able to couple to the ST25DV's antenna. I am also using an STM designed ST25DV dev board / breakout where I have short wires soldered to the breakout's through holes and wired back to my PCB's terminal block.

[JL. Lebon]

Ok, so the point is still to determine who is faulty:

• is the RF not writing data correctly?
• or is I2C not reading data correctly?

The simplest to check is I2C. Have you been able to connect an oscilloscope to the I2C bus to see what is really happening when wrong data is read ?

Best regards.

[Ulysses HERNIOSUS · Accepted solution]

Hi KKosi,

I quickly did an analysis of the expected pattern vs the received pattern on I2C:

1    2    3    T    e    s   t    E    n     t    r    y
0x31 0x32 0x33 0x54 0x65 0x73 0x74 0x45 0x6e 0x74 0x72 0x79
0x10 0x20 0x33 0x54 0x45 0x62 0x74 0x40 0x68 0x30 0x32 0x31

If you inspect the hex digits you can see that line 3 compared to line 2 shows only bits going from 1->0 and never from 0->1.

Possible explanation for this could be two I2C devices driving data. I2C with its pull-ups and devices only driving zeroes allows exactly such behavior.

When inspecting as suggested by JL. Lebon using a scope you could possibly see this: Some 0 would be stronger / lower than others when both devices are driving a 0. But you need to watch out for such.

Best Regards Ulysses

[KKosi]

I have found that my EEPROM M2402 was interfering. I pried it off my PCB and now I can read from the NFC device properly.

Thank you.