2023-02-05 09:37 AM
I am working with an App developer to read/write to an ST25DV Dynamic Tag. The project does the following:
1 App writes to the ST25DV a short NDEF Text record (15 bytes), the App then goes into some kind of wait mode
2 Host micro reads the tag using I2C
3 Host decodes data read and sends a reply record using I2C
4 After approx 1 second the App reads the ST25DV tag.
This works perfectly with phones running Android 8 and Android 11 but does not work properly with Android 13. The ST25DV is written OK. The host micro read/writes properly but the the app returns an error message Last Exception,"Bad state:no Element".
What does this message mean and wht would I get it when the older Android versions seem to work fine.
Any help would be great.
Solved! Go to Solution.
2023-02-17 01:53 AM
Hi Steve,
We suspect that your problem is related to the smartphone's presence check. The smartphone will periodically check if something is present in the RF field and, when a tag is found, it will also check periodically if it is still present. The presence check usually happens every 130ms. The difficulty is that each phone has a different way of handling the RF object detection, the anti collision and the inventory. So different phones may behave differently and may lead to different results.
If a presence check command happens during an I2C command, it will fail with a TimeOut because the NFC Tag will not be able to answer it. This can cause some problems during your sequence because the smartphone may think that the tag is gone (and this is here that different phone will behave differently).
In a previous project, we had such problem and here is how we have worked it around:
Instead of using the standard mode we have used a reader mode (see this link) which allows to control the periodicity of the presence checks thanks to EXTRA_READER_PRESENCE_CHECK_DELAY. By increasing the presence check period to 500 ms we avoided the problem.
It seems that this mode is also available on Flutter: https://pub.dev/packages/nfc_manager
You may want to try it.
FYI, I would like also to mention that the ST25DV has a Fast Transfer Mode feature that is well adapted to bidirectional communication and much faster than communication via tag's EEPROM memory. It uses a RAM of 256 bytes present in the ST25DV. When some data are put in this mailbox, the MCU can be informed by the interruption so it avoids that the MCU does some polling to know if an NDEF has been written.
Our ST25SDK has an API to simplify the use of this Fast Transfer Mode. A single API function can be called to send or receive data of any size. The ST25SDK will take care of the transmission.
This looks well adapted to your need, unfortunately it is not available by default on Flutter so some porting is necessary.
Regards
Olivier
2023-02-13 12:59 AM
We are not aware of this issue and have never seen this exception. Which phone did you use for this test?
I have a Google Pixel 6 running Android 12. This week I will update it to Android 13 and I will keep you informed.
Regards
2023-02-13 01:08 AM
2023-02-13 01:18 AM
Hi Steve,
Yes, it might be related. You see the same issue with 3 different phones (from different brands) so something has changed for sure. We will test and come back to you.
Regards
Olivier
2023-02-16 02:37 AM
Hi Steve,
I have flashed my google Pixel 6 phone with Android 13 (I'm using the image oriole-tq1a.230205.002-factory-f6f5ac27).
I have installed ST25 NFC Tap application and tested some tags (ST25DV64KC and ST25DV04K) but I don't see problems.
Can you please tell me the reference of the tag that you're using? In Tag Info, you can read the UID and in System File you can read the ICRef. Please send me these info.
Then, with a working smartpone (you mentioned Android 8 or 11 phones), please go to Memory tab -> Read memory. Dump the first 64 bytes of the memory and please send me a screen shot. It will help me to see the CC File present in the tag.
Thank you
Regards
Olivier
2023-02-16 02:57 AM
I was rereading your first message. I see that Android 13 phone is in fact writing an NDEF successfully, right? The problem seems to come later on.
"the App then goes into some kind of wait mode"
Would you have more info about his?
Can you please give the content of the two NDEF messages exchanged? It is possible that the smartphone doesn't "like" the NDEF message written by the host.
Do you respect the procedure when writing this NDEF? The NDEF length should be set to 0 and updated as a last operation when all the bytes are ready.
We have also thought to a possible collision between a RF command and an I2C command. In that case you would have the following result:
It doesn't seem to be what you have.
One last thing. Are you using the ST25SDK? If yes, you should take care to the Cache.
When the smartphone writes the first NDEF, the content will be saved in the cache.
The tag's memory is then updated by the host (let's call that NDEF2) but the smartphone is not aware of that.
If the smartphone tries to read the NDEF message, it will get the NDEF1 present in Cache.
That's why it is important to flush the cache.
Regards
2023-02-16 06:02 AM
2023-02-17 01:53 AM
Hi Steve,
We suspect that your problem is related to the smartphone's presence check. The smartphone will periodically check if something is present in the RF field and, when a tag is found, it will also check periodically if it is still present. The presence check usually happens every 130ms. The difficulty is that each phone has a different way of handling the RF object detection, the anti collision and the inventory. So different phones may behave differently and may lead to different results.
If a presence check command happens during an I2C command, it will fail with a TimeOut because the NFC Tag will not be able to answer it. This can cause some problems during your sequence because the smartphone may think that the tag is gone (and this is here that different phone will behave differently).
In a previous project, we had such problem and here is how we have worked it around:
Instead of using the standard mode we have used a reader mode (see this link) which allows to control the periodicity of the presence checks thanks to EXTRA_READER_PRESENCE_CHECK_DELAY. By increasing the presence check period to 500 ms we avoided the problem.
It seems that this mode is also available on Flutter: https://pub.dev/packages/nfc_manager
You may want to try it.
FYI, I would like also to mention that the ST25DV has a Fast Transfer Mode feature that is well adapted to bidirectional communication and much faster than communication via tag's EEPROM memory. It uses a RAM of 256 bytes present in the ST25DV. When some data are put in this mailbox, the MCU can be informed by the interruption so it avoids that the MCU does some polling to know if an NDEF has been written.
Our ST25SDK has an API to simplify the use of this Fast Transfer Mode. A single API function can be called to send or receive data of any size. The ST25SDK will take care of the transmission.
This looks well adapted to your need, unfortunately it is not available by default on Flutter so some porting is necessary.
Regards
Olivier
2023-03-29 05:48 AM
Hi Steve,
FYI, a change of behavior happened on Android 13 concerning the peristence of the Android Tag handle.
More information is available on this thread:
A fix has been implemented.
Regards
Olivier