Energy Harvesting not available when RF is sleep or disabled

[REdmo.1]

In the ST25DV data sheet, I read:

"Energy harvesting can be set even if ST25DVxxx is in RF disabled or RF Sleep mode, or in Low power mode. In all these cases, ST25DVxxx will deliver power on V_EH pin if RF field is present."

However this is not what I am seeing.

If energy is being harvested to power the MCU and it sets either RF_DISABLE or RF_SLEEP in RF_MNGT_Dyn via i2c ,the energy harvesting output disappears and the system dies.

Is this an error in the data sheet or is there a way to disable/delay enabling RF communications whilst maintaining Energy Harvesting?

I suppose that the possibility exists that the phone is switching off the field when RF communications are disabled, but this amounts to the same thing.

I want to be able to delay RF communications until the MCU has written the NDEF record to the EEPROM, i.e. I want to power up from harvested energy with RF communications initially disabled.

Thanks,

Richard

[REdmo.1]

Hi JL,

I love your idea of jumping in after the successful inventory command and disabling the RF to prevent the phone reading the NDEF records thereby giving the microcontroller time to write the new NDEF record in the gap before the next Inventory command. [It might increase the power consumption though if the microcontroller has to run at full speed.]

Indeed, I suspect my design is already doing something not dissimilar to prevent the i2c writes causing the phone to collapse the field. The microcontroller watches the activity output of the ST25DV and ensures that all i2c writes happen immediately after the phone has accessed the tag. Otherwise conflicts occur and things go badly wrong.

My first concern was that my experiments indicate that setting any bits in RF_MNGT_Dyn causes the phone to lose contact with the tag and remove the NFC field. [Indeed, I am currently using this behaviour in the demonstration to create a second session.] However, it sounds like that it was a result of the Inventory command failing rather than a request for NDEF record failing and that as long the RF is enabled at the point that the Inventory ("ping"?) command arrives, the phone should be happy to maintain the field even though it hasn't yet read the NDEF records.

Indeed, I wonder if this could continue across a number of polling cycles. If the microcontroller can disable the RF immediately after each Inventory ping command, might there be multiple windows each of a few hundred milliseconds which the microcontroller can use to write to the EEPROM as long as it disables RF long enough to thwart the phone NDEF access, but not so long that it risks thwarting the next ping?

Indeed, does the microcontroller even have to disable the RF? Wouldn't the action of performing the i2c writes (as long as they could start quickly enough) be sufficient to get the arbitration system within the ST25DV to return errors to the phone when it tries to get the NDEF?

There must be so many possible NFC sensor applications that would like the ability to update NDEF records before they are accessed by the phone. Perhaps the next generation of ST25DV will have separate controls for returning errors to the Inventory command and for other commands. That would be a real attraction. Especially if it could handle the problem caused by i2c accesses happening during a ping from the phone.

This has been a fantastic learning experience for me. The application note is gold-dust and the suggestion about using RF_DISABLE to selectively return errors for different phone commands based on timing is one I really want to explore.

Many thanks,

Richard

[JL. Lebon]

Hi Richard,

I'm happy that you like my idea.

Let me quickly answer some of your questions.

"However, it sounds like that it was a result of the Inventory command failing rather than a request for NDEF record failing and that as long the RF is enabled at the point that the Inventory ("ping"?) command arrives, the phone should be happy to maintain the field even though it hasn't yet read the NDEF records."

=> actually, as long as the phone gets answers to requests, even if it is errors, it keeps the RF field ON. A non answer to any command (not only Inventory) is interpreted as "tag lost" and the field is set OFF.

"Indeed, I wonder if this could continue across a number of polling cycles. If the microcontroller can disable the RF immediately after each Inventory ping command, might there be multiple windows each of a few hundred milliseconds which the microcontroller can use to write to the EEPROM as long as it disables RF long enough to thwart the phone NDEF access, but not so long that it risks thwarting the next ping?"

=> Yes, that would be possible. After the first NDEF reading have failed, the phone will not try to read it again. Only ping inventory are sent. So you can as many windows as you want to write your NDEF.

"Indeed, does the microcontroller even have to disable the RF? Wouldn't the action of performing the i2c writes (as long as they could start quickly enough) be sufficient to get the arbitration system within the ST25DV to return errors to the phone when it tries to get the NDEF?"

=> Actually no, it will not work. The reason is that by default, the phone is using the ISO15693 "addressed mode". When I2C is busy and a non-addressed command is received, the RF command is answered with error 0F. But when I2C is busy and a addressed command is received, the RF command is not answered.

That's the reason why it is better to use the RF disable mode and why it is so important to avoid conflict between I2C and RF commands.

Best regards.

[REdmo.1]

Hi JL,

Thanks for these responses.

>RF_DISABLE mode that answers an error to any command....unfortunately it doesn't answer the inventory command

Ah is this why RF_DISABLE must be set low during Inventory ping i.e. because RF_DISABLE causes no response to be sent during an Inventory ping and the phone receiving no answer would cause a phone disconnect?

Conversely, RF_DISABLE can be high during all other commands because an error is sent for them and so the field is maintained.

>After the first NDEF reading have failed, the phone will not try to read it again.

Do you mean it will never try to read it again? Or that it won't try to read it again until after the next successful Inventory ping? The latter I hope, otherwise the microcontroller will have written the EEPROM but the phone will never read it until after it loses contact with the tag.

>it is so important to avoid conflict between I2C and RF commands.

Is there any way that the next generation of ST25DV will handle this for us by internally synchronising writes to the trailing edge of the BUSY signal when it is connected to a phone.

I guess there is no way of stopping the phone accessing the EEPROM at other times, but for a NFC sensor application that may not be an issue.

Thanks for your help with this. It is really helpful and really appreciated.

Richard

[JL. Lebon]

Hi Richard,

"Ah is this why RF_DISABLE must be set low during Inventory ping i.e. because RF_DISABLE causes no response to be sent during an Inventory ping and the phone receiving no answer would cause a phone disconnect?

Conversely, RF_DISABLE can be high during all other commands because an error is sent for them and so the field is maintained."

-> Yes, exactly.

"Do you mean it will never try to read it again? Or that it won't try to read it again until after the next successful Inventory ping? The latter I hope, otherwise the microcontroller will have written the EEPROM but the phone will never read it until after it loses contact with the tag."

-> The phone tries to read the NDEF message only after the first anti-collision. The next Inventory pings are only here to check the presence of the tag, but no more NDEF reading will be tried.

Consequently, if you want the phone to read the NDEF, you have to make it "rediscover" the tag. This can be done by not answering one of the Inventory ping, letting it think the tag is not present. The phone will then do a RF field off, then do a RF field ON after a while and start a new full anti-collision loop including the NDEF read. This will be noticed by the end-user as a sound will be emitted by the phone again.

Not a nice solution, but I don't see how to do otherwise.

"Is there any way that the next generation of ST25DV will handle this for us by internally synchronising writes to the trailing edge of the BUSY signal when it is connected to a phone.

I guess there is no way of stopping the phone accessing the EEPROM at other times, but for a NFC sensor application that may not be an issue."

-> Yes, next generations will handle this differently.

Best regards.

[REdmo.1]

Hi JL,

Sorry for the delay in responding - I have been away for the past week.

With your guidance, I think I am closing in on a solution.

In our application, we cannot hope to update the NDEF record within 30ms and since it is not possible to use more than one ping "frame" to write the NDEF record ("the phone tries to read the NDEF message only after the first anti-collision"), I am planning, as you suggest, to have the phone "rediscover" the tag by not answering one of the Inventory pings, thereby letting it think the tag is not present.

I think this "two session" solution (where the first message is discarded and the fresh sensor data is obtained after the re-connect) could work okay for our application.

The major challenge is then to avoid the i2c and the RF accessing the ST25DV EEPROM at the same time. Section 2.2 of the application note seems to suggest that this is a relatively trivial matter and section 2 states "the asynchronous method does not imply specific techniques", but I am finding that its not trivial.

In avoid catastrophic conflicts due to simultaneous RF and i2c accesses to the ST25DV EEPROM, I am currently looking at a scheme whereby i2c EEPROM access request packets are placed in a queue by a main thread and then an interrupt routine, triggered by the rising edge of the RF_BUSY signal tries to process as many as it can within a "safe" period after that edge. If the only activity by the phone is to "ping" for the presence of the tag, then it seems that this safe period might be a couple of hundred milliseconds. This might be okay for our application but it doesn't seem as trivial as the Application Note might suggest.

In cases where there are other accesses from the phone to the ST25DV EEPROM (our previous solution required two-way communication), I fear these might happen at any point during the ping frame, and so I suspect that the only safe way to do this is by employing the "Fast Transfer Mode" which I believe does not have the same conflict issues.

The good news is that I haven't yet found any insurmountable obstacles to the scheme we plan to use. The requirement to maintain a non-volatile "tap counter" in the ST25DV EEPROM to detect stale "first session" messages is cumbersome, but hopefully should be workable.

Thanks again for your help,

Richard

[JL. Lebon · Accepted solution]

Hello Richard,

I'm glad you made progress in your design.

Concerning simultaneous access to the ST25DV, your solution of queueing the I2C writes looks clever.

You have to consider also that an I2C write in the EEPROM memory does not end at the STOP bit, but when the programming in the EEPROM is really completed (programming starts at the STOP bit and duration is dependent of the number of Bytes that are programmed). The I2C is considered "busy" during this programming time and RF cannot access the ST25DV during this time, even if the I2C bus is free.

This is all explained in (yet another 😀) application note: https://www.st.com/resource/en/application_note/an5624-how-to-manage-simultaneous-ic-and-rf-data-transfer-with-an-st25dvxxkc-device-stmicroelectronics.pdf

This application note may help you to improve avoiding simultaneous accesses.

Best regards.

[REdmo.1]

> your solution of queueing the I2C writes looks clever.

And it seems to work nicely on the ST25DVxxK. But not on the ST25DVxxKC.

I see from the Application Note 5633 that the bit assignments in the GPO (now GPO1) register have changed. For ST25DV04K, I was setting GPO=0x82 and IT_TIME=0x03. For ST25DVxxKC, I am setting GPO1=0x14 and GPO2=0x0C.

At the moment, this isn't working [I even went back to the ST25DVxxK to validate the hardware].

I'll trawl AN5633 to see if i can find any other relevant differences. I'll also study the AN5624 application note to see if there is any fundamental reason why I cannot use the same scheme on ST25DVxxK and ST25DVxxKC as long as their GPO registers are set correctly.

[REdmo.1]

>I am setting GPO1=0x14

D'oh! It should be 0x05. Now it works on ST25DVxxKC. <embarrassed>

[JL. Lebon]

Hello Richard,

Yes, the ST25DVxxKC has different GPO registers as it has more interruptions than the K version. This can be a trap, don't be embarrassed 😀

I'm glad this solution works well. I think I will update the AN, adding this solution so that others can also benefit from this.

Best regards.