two different chips connected to one I2C bus. is any delay/reset/cycle needed?

[JanG]

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:

• One chip is a ST25DV04K
• The other chip is another Memory-EEPROM
• Both have the same device identifier, but different bits in the chip enable address

=> 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:

• Chunks are sent from app to MCU via ST25 mailbox
• MCU checks data
• MCU saves data in Memory-EEPROM
• Delay for sync on both sides (avoid parallel access)
• MCU sends back one chunk via mailbox
• App starts polling status of mailbox
• App detects ‘tag lost’

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.

• I wonder if there is any delay/reset/cycle I missed in the datasheet. Do you have any clues?
• Is there any low level NFC communication, I’m not aware of, that causes usage RF and I2C at the same time?

Thank you very much for your help!

BR,

Jan

[JL. Lebon]

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)

• What is the I2C device address of the EEPROM ? (I'm sure you have already checked this anyway).
• Can you please tell me the exact version of the ST25DV04K you are using? (there is different packages and GPO versions).

Best regards.

[JanG]

Hi,

thank you very much for your response! As you requested:

• The other I2C EEPROM is using the addresses A0/A1
• The ST25DV04K is used as SO8 chip

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:

• An single event for a ‘new tag’.
• The combination of ‘new tag’ and ‘tag lost’.

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.

[JL. Lebon · Accepted solution]

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:

• MCU sends back one chunk via mailbox
• App starts polling status of mailbox

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:

• Chunks are sent from app to MCU via ST25 mailbox
• MCU checks data
• MCU saves data in Memory-EEPROM
• Delay for sync on both sides (avoid parallel access)
• MCU write backs some data into ST25DV's EEPROM user memory
• Delay for sync on both sides (avoid parallel access)
• App reads the data into ST25DV's EEPROM user memory

Best regards.

[JanG]

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!