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]

I'm starting to wonder if this is in fact phone behaviour. How would I find out more about how phones control their NFC fields to detect and power NFC tags?

Perhaps the phone only raises the strength of its NFC field sufficiently to enable energy harvesting if it can communicate with the tag. Perhaps it is necessary for the phone to have successfully read whatever it reads plus any NDEF records before it raises the field strength. Perhaps it reduces the field strength if RF communications with the tag are disabled causing the the tag to power down. There's a lot I don't know about phones and it seems I need to know it. How might I find out?

This tends to suggest that setting any of the bits in RF_MNGT would effectively "brick" the NFC tag. From that point forward, the phone can no longer access the tag over RF and since there is no power on the tag (since there is no communication), neither can the MCU over i2c.

My challenge is that I want to populate a URI NDEF record BEFORE the phone reads it in order to transfer sensor data to the cloud. [My previous plan was only to enable RF communication AFTER the NDEF record had been written by the MCU to the ST25DV. There is no app on the phone.]

How do those sensor systems communicate their data to the cloud?

[Ulysses HERNIOSUS]

Hi Richard,

a phone will typically perform a polling loop with field on, send some commands (typically going through NFC-A, NFC-B, NFC-F and NFC-V defined in NFCForum Digital and Activity spec) and if nothing is found turn off the field again. This whole procedure will probably last something in the ~50 to 100ms range. A tag according to standard is expected to be able to answer after ~5ms.

As all phones that I know go through the other technologies first which will buy you some 30+ms but likely not enough for you to write a complete NDEF and enable RF.

My tag colleagues will be able to comment on approaches for your use case.

Best Regards, Ulysses

[REdmo.1]

Thanks for this - it makes sense.

I'm not quite clear exactly what is meant by "nothing is found" and "answer" but the gist is clear.

I would have imagined that the scheme whereby an "intelligent" tag with a sensor constructs a URI NDEF record to pass sensor values to the cloud might be a popular solution. But I haven't found a way to make it work nicely yet.

At the moment, the best I can think of is to have the RF field initially enabled in the ST25DV and then to use harvested energy to power the MCU to write the NDEF record. If the MCU then set bits in RF_MNGT_Dyn to disable RF, I find that the phone removes the field, the RF state reverts to that specified by RF_MNGT i.e. on and the process starts again, but this time with the sensor data already in the NDEF record. The tag is effectively triggering a reboot.

This is just about ok for the proof of concept demonstrator I am building, but you can see the obvious problems with it

1. how does the cloud know which NDEF records are valid and which not => I'm currently adding a incremented "sequence" parameter in the NDEF record - yuk!
2. after the restart, the MCU will start writing the sensor values again so the tag needs to be removed quickly form the field after the second "bing-****" => potential corruption

Using a URI NDEF seems like a nice way to use a phone as a conduit between a sensor tag and the cloud, but I haven't yet found a nice way to do it. Has anyone else?

Thanks,

Richard

[JL. Lebon]

Hello,

I think what you are trying to do is explained in detail in the application note AN5439 https://www.st.com/content/ccc/resource/technical/document/application_note/group1/fa/bc/7d/fc/e1/d9/4f/83/DM00682138/files/DM00682138.pdf/jcr:content/translations/en.DM00682138.pdf

It explains and give examples of dynamic NDEF using the ST25DV.

I confirm that your analysis is correct: in RF Sleep mode, as the tag is not answering to the Inventory command send by the phone to discover the tag, most of the phone will shutdown the RF field (for several hundred ms before trying again).

This means you cannot "buy" time to update your NDEF file before the phone reads it (as the next command after the inventory is to read the CC file and the NDEF file) as you will lost the EH power.

You just have a short window of about ~30ms to update your NDEF file.

Hope the application note can help you in your project.

Best regards.

[REdmo.1]

Hi JL,

Many thanks for this application note. I will read it and respond.

Richard

[REdmo.1]

Hi JL,

This Application Note is brilliant. There is so much in it that relates directly to our application....stuff I had to find out the hard way, but now can read about....still reading...

Very grateful,

Richard

[JL. Lebon]

Thank you, I'm glad it helps you! :grinning_face:

[JL. Lebon]

Hello Richard,

Your solution is smart!

As you understood, the main issue is that if the tag doesn't answer to the inventory command, it is considered lost and the field is shut down.

We do have the RF_DISABLE mode that answers an error to any command. But unfortunately it doesn't answer the inventory command either since the ISO15693 standard doesn't allow it.

But it may be possible to do something with this RF_DISABLE mode...

Indeed, any error answered during the NDEF read by the phone cancels this NDEF reading. But an error doesn't make the phone cut the field. After an error, the tag is still considered to be present and the phone will periodically checking the tag's presence by sending periodical Inventory commands (every few 100ms depending on phones).

So, the idea would be to set the tag in RF_DISABLE mode right after the first inventory.

That way, next command would fail and the phone would stop reading the NDEF. You would then have until the next Inventory command to update the NDEF from I2C (a few 100 ms).

After this, the next Inventory would not be answered as the tag is still in RF_DISABLE state: and the phone would cut the RF field and start the discovery process again, reading the new NDEF.

Detecting the first Inventory command is the tricky part.

You would need to detect the field rising interrupt and then the first RF_ACTIVITY interrupt triggered by the first inventory command.

On this RF_ACTIVITY interrupt, you would have a few ms (no more than 5ms I guess) to set the tag in RF_DISABLE mode by writing RF_MNGT_Dyn from I2C (the ISR has to read the IT_STS register and write the RF_MNGT_Dyn register very quickly) . This is tricky on timing...

To debug all those timings, I recommend you to use a scope with a probe on SDA/SCL, a probe on VEH and a small one-loop wire "antenna" on the antenna of the tag, connected to a probe as well, to monitor the RF field (this is the way the screenshots of the AN have been made)..

Sorry if this this idea does not work or help you, It is just quick thinking :beaming_face_with_smiling_eyes:

Best regards.

[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]

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 :grinning_face:) 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>