2021-12-13 11:20 PM
Hi at all,
I'm facing a ‘tag lost’ problem with two different chips connected to one I2C bus. I didn’t find a similar scenario, so here is mine:
=> AFAIK this should be possible, correct me if I’m in the wrong here
I’m using an Android app for NFC communication. The mailbox in the ST25DV04K is used to exchange chunks of data in both directions.
Since RF and I2C is not supported at the same time, delays/timeslots are added to avoid access the ST25DV04K at the same time. The MCU using the GPO with an interrupt.
=> As long as there is only exchange between the Android app and the MCU (STM32) it works just fine.
If there is a write access to the other Memory-EEPROM (save data between 100B and ~16kB), the Android app detects a ‘tag lost’ in most cases.
The exchange can be seen like this:
After the ‘tag lost’ was detected, the app starts a retry. It reads back the bits for ‘HOST_PUT_MSG’ and ‘HOST_CURRENT_MSG’ in the mailbox status.
Different timings were tested. Different clock speeds (100kHz and 200kHz) were tested. Different ST25DV04K chips were tested. Voltage signals seems to be ok.
Thank you very much for your help!
BR,
Jan
Solved! Go to Solution.
2021-12-20 12:34 AM
Hello,
I'm glad everything is working as expected on the I2C side.
Still, I can't see the relationship between the second I2C device and the tag lost situation...
May be, there is a "collision" between RF and I2C when you are doing the polling:
At this point, if the app is doing some polling while the I2C is writing data in the mailbox, the RF command will not work. There is two different possibilities here. If the RF polling command has not been sent in addressed mode, the ST25DV will return an error 0x0F. No problem in that case. But if the RF polling command has been sent in addressed mode, the ST25DV will not answer. In that case, the smartphone will receive no answer and will think the tag is lost.
This may be your issue. Can you check if the polling command is sent in addressed mode ? If yes, can you try using the same polling command but in non addressed mode ?
Another test that you may do is to check a normal RF read or write into EEPROM instead of using the mailbox, just to see that RF communication is still working fine. The steps would be:
Best regards.
2021-12-17 01:32 AM
Hello,
It is possible to connect the ST25DV on the same I2C bus as other i2C devices. Off course, there respective I2C addresses must be different.
The ST25DV04K has 4 different addresses: A6/A7 for the user memory and AE/AF for the system memory (this includes the device select code, the chip select bits and the R/W bit).
Normally, when another I2C device is accessed, the ST25DV is in "I2C Busy" state during the decoding of the I2C device address (from the start condition up to the acknowledge bit). This time is quite short and should not impact your application whit the timing you are describing. (there is an application note available that explains this mechanism : https://www.st.com/resource/en/application_note/an5262-how-to-manage-simultaneous-ic-and-rf-data-transfer-with-an-st25dvxxk-device-stmicroelectronics.pdf)
Best regards.
2021-12-19 11:54 PM
Hi,
thank you very much for your response! As you requested:
I did some more testing meanwhile and double check the stop conditions. They are executed as mentioned in the data sheet (and application note), so no problem here.
I added an I2C request for the ST25 after writing my other EEPROM. The ST25 sent its response as expected, so I assume the I2C side is fully functional and the ST25 is back to idle.
Regarding my ‘tag lost’ problem, I detected different behaviours on the mobile app side:
The smartphone switches off the RF field sometimes without app/user input/command. I’m not sure if there an RF error and the smartphones tries a ‘recovery’ or the smartphone issues the problem.
=> Trying to add some more robustness in the app. That might be suitable as a workaround, but I have still no clue about the root cause.
Best regards.
2021-12-20 12:34 AM
Hello,
I'm glad everything is working as expected on the I2C side.
Still, I can't see the relationship between the second I2C device and the tag lost situation...
May be, there is a "collision" between RF and I2C when you are doing the polling:
At this point, if the app is doing some polling while the I2C is writing data in the mailbox, the RF command will not work. There is two different possibilities here. If the RF polling command has not been sent in addressed mode, the ST25DV will return an error 0x0F. No problem in that case. But if the RF polling command has been sent in addressed mode, the ST25DV will not answer. In that case, the smartphone will receive no answer and will think the tag is lost.
This may be your issue. Can you check if the polling command is sent in addressed mode ? If yes, can you try using the same polling command but in non addressed mode ?
Another test that you may do is to check a normal RF read or write into EEPROM instead of using the mailbox, just to see that RF communication is still working fine. The steps would be:
Best regards.
2021-12-20 11:23 PM
Hello,
Thank you again for your help! I’ll forward your suggestions for testing the RF communication.
Due to upcoming Christmas vacation I don’t expect any progress in this year. I’ll keep you posted if I have new input.
Merry Christmas!