cancel
Showing results for 
Search instead for 
Did you mean: 

How to detect "writing to EEPROM from APP" via I2C communication

MMoro.4
Associate II

Hello all

I use ST25DV64K.

If I2C communication is used to access EEPROM while APP is writing to EEPROM, it will cause an error on APP side.

Therefore, I would like to check the status of the NFC tag when it is being written from APP.

And while writing from APP I want not to access by I2C communication, how can I do this?

Is it possible to find out by reading a register somewhere?

I thought one of the "IT_STS_Dyn" would be set to "1" while writing the EEPROM of the NFC tag from APP, but they all stayed at "0".

BR

Morooka​

1 ACCEPTED SOLUTION

Accepted Solutions
JL. Lebon
ST Employee

Hello Morooka,

IT_STS_Dyn works as you think. Once you read the RF_WRITE bit, write operation is already finished. The exact write timing is only available from the level of the GPO pin.

But anyway, I think your issue is not only with RF write operations. The point is that access to the ST25DV from one interface (RF or I2C) is exclusive, whatever you are reading or writing.

For instance, from the start of frame of an RF request, to the end of frame of the answer, the access from I2C is forbidden, even if RF is only reading the tag.

In the same way, from after a valid I2C device selection and until the stop condition, the I2C locks the access and RF cannot access the tag.

This is all explained in an application note, "AN5262 How to manage simultaneous I²C and RF data transfer with an ST25DVxxK device" https://www.st.com/resource/en/application_note/an5262-how-to-manage-simultaneous-ic-and-rf-data-transfer-with-an-st25dvxxk-device-stmicroelectronics.pdf

I think you can find your answer in this application note.

There is several ways to solve your issue. The simplest is by doing some polling to check the availability of the interface. You also have the possibility, on I2C side, to mute the RF is needed by entering the RF_SLEEP mode. You can also detect RF activity by using GPO interrupt RF_ACTIVITY. You can also monitor the RF field (you can do it with RF_FIELD_RISING and RF_FIELD_FALLING GPO interrupts). And you can combine those solutions to get something more accurate.

Best regards.

View solution in original post

4 REPLIES 4
JL. Lebon
ST Employee

Hello Morooka,

By "APP is writing to eeprom", I guess you mean EEPROM is written from RF interface ?

It is possible to get an interrupt on the GPO pin when the RF interface writes into the EEPROM.

The RF_WRITE interrupt must be enabled in the GPO static register (bit 6 RF_WRITE_EN=1 and bit 7 GPO_EN=1).

Then, whenever the RF is writing into EEPROM, the GPO pin will be tied low during the write time. the interrupt whill also be visible in IT_STS_Dyn register.

Please see chapter 5.2 GPO in the St25DV64K datahseet (see specifically RF_WRITE interrupt part)

Best regards.

MMoro.4
Associate II

Hello JL.Lebon,

Thank you for your answer.

"APP is writing to eeprom" means "writing" from RF interface to EEPROM.

It does not mean "write completed" from RF interface to EEPROM.

Is it correct to my understand that the operation of RF_WRITE of IT_STS_Dyn is as follows?

Operation RF_WRITE

Writing to EEPROM from RF interface 0

Writing to EEPROM from RF interface completed 1

In the above case, when EEPROM is being written from the RF interface, it cannot be detected by the I2C host.

Is there any way to detect that EEPROM is being written from the RF interface from the I2C host?

If there is no way to detect it, is it appropriate to check "FIELD_ON" in the EH_CTRL_Dyn register and prevent the I2C host from accessing the EEPROM while "FIELD_ON" is ON?

Best regards​

JL. Lebon
ST Employee

Hello Morooka,

IT_STS_Dyn works as you think. Once you read the RF_WRITE bit, write operation is already finished. The exact write timing is only available from the level of the GPO pin.

But anyway, I think your issue is not only with RF write operations. The point is that access to the ST25DV from one interface (RF or I2C) is exclusive, whatever you are reading or writing.

For instance, from the start of frame of an RF request, to the end of frame of the answer, the access from I2C is forbidden, even if RF is only reading the tag.

In the same way, from after a valid I2C device selection and until the stop condition, the I2C locks the access and RF cannot access the tag.

This is all explained in an application note, "AN5262 How to manage simultaneous I²C and RF data transfer with an ST25DVxxK device" https://www.st.com/resource/en/application_note/an5262-how-to-manage-simultaneous-ic-and-rf-data-transfer-with-an-st25dvxxk-device-stmicroelectronics.pdf

I think you can find your answer in this application note.

There is several ways to solve your issue. The simplest is by doing some polling to check the availability of the interface. You also have the possibility, on I2C side, to mute the RF is needed by entering the RF_SLEEP mode. You can also detect RF activity by using GPO interrupt RF_ACTIVITY. You can also monitor the RF field (you can do it with RF_FIELD_RISING and RF_FIELD_FALLING GPO interrupts). And you can combine those solutions to get something more accurate.

Best regards.

MMoro.4
Associate II

Hello JL.Lebon,

 Thank you for telling me about the Apllration Note.

This note has been very useful for me.

I understand well about I2C busy and RF busy.

Also, thank you for showing me some methods.

I will be able to develop the software with the information you gave me.

Thank you very much!