ST25DV04K - possible bug with FTM after using Manage GPO set/reset commands?

JButc.1 · ‎2021-11-01

Hi,

We have an ST25DV04K NFC tag which is being used to communicate to a host microcontroller from a mobile app and we're having trouble with FTM after booting up the host device from the app.

We're starting up the host from this app by pulsing the GPO line. Unfortunately, the maximum interrupt time is too short so we're generating a pulse with the Manage GPO command; set, wait 1ms, reset. This works great.

Once the device boots up, it then configures the tag to disallow RF from controlling the GPO with the Manage GPO command (by setting RF_USER_EN to 0 in GPO register).

Then, we need to send some data to the host via FTM. So we enable the mailbox and write our data. On the host side, we see the interrupt, check the IT_STS_Dyn register for RF_PUT_MSG, then read the data, calculate the CRC, then write that back to the mailbox.

This is where there's an issue. The mobile app is now polling the MB_CTRL_Dyn register for HOST_PUT_MSG. However, that never happens. Even stranger, if we move the phone away from the host device, then back, then repeat the process from enabling the mailbox, it all works.

Also, the watchdog doesn't seem to time out, i.e. RF_MISS_MSG is never set either.

Are there any known issues related to this? Is the presence of the RF field maintaining some state which doesn't allow the tag to change the MB_CTRL_Dyn register?

Any help would be much appreciated!

JL. Lebon · ‎2021-11-16

Hello,

I'm not sure I understand what you are saying about "us sending an error response that's not being accepted".

Have you tried to use the MB_CTRL_Dyn register to control the flow between I2C and RF as suggested ?

Best regards.

View solution in original post

JButc.1 · ‎2021-11-01

Update - it turns out the max interrupt time is in fact long enough to power up the unit. However, we still see the same issue with HOST_PUT_MSG never being set.

JButc.1 · ‎2021-11-03

-

JL. Lebon · ‎2021-11-08

Hello,

Concerning the watchdog issue, this is a known issue. when writing a message in the mailbox from I2C, the watchdog is started only after the next I2C stop condition. There is an easy workaround for this: to send a single I2C polling command immediately after an I2C write message in mailbox. This I2C polling command can be a single byte, containing only the I2C slave address of the ST25DV-I2C with the Read/Write bit set to 0 (i.e. START/AEh/Ack/STOP). It starts the watchdog counter and therefore must be sent with a minimum delay after the I2C write message command.

Now concerning the issue with HOST_PUT_MSG bit not set, there is no known issue like the one you describe.

In order to understand what happens here, I would need some additional information.

Can you please confirm that after the host has read the message the RF_PUT_MSG bit is correctly cleared ? (you can check it with an I2C read of the MB_CTRL_Dyn register) This bit is cleared when the last byte of the message has been read, so the host needs to read the full message.
Then, can you please confirm that when writing the message in the mailbox from the host, you get no NACK bit ?
Still after the host has written the message, can you please read the MB_CTRL_Dyn register from I2C side to check if the HOST_PUT_MSG is set to 1 ?

Best regards,

JButc.1 · ‎2021-11-10

Hi, thanks for your response.

All of our debugging previously was from the mobile side. In light of what you've said we've been concentrating more on the i2c side - I've produced the attached log which shows the issue is not to do with a failure of the tag to flip the HOST_PUT_MSG bit, but to do with the i2c host being able to read the mailbox.

The timestamp on the left is ms since host boots up. Please note that the 'RESTARTING' is triggered by our host fw. It power cycles the nfc tag after the 5th no ACK received. Everything appears to begin working around line 42, when the host is then able to read the mailbox and act upon it.

Please let me know if you need more info, we're still very stuck on this one!

Best regards,

Jack

0000502: Password accepted
0000510: Static config
 GPO = 0x84
 MB_MODE = 0x01
0000511: Entering RFID mode
0000512: Configuring GPO control - awake
0002028: Dynamic config
 IT_STS_Dyn = 0x20
 RF_PUT_MSG
0002528: ERROR: no ack
0002530: ERROR: no ack
0002532: ERROR: no ack
0002534: ERROR: no ack
0002536: RESTARTING
0003537: Password accepted
0003545: Static config
 GPO = 0xBC
 MB_MODE = 0x01
0003546: Dynamic config
 IT_STS_Dyn = 0x10
 FIELD_RISING
0003548: Configuring GPO control - awake
0003859: Dynamic config
 IT_STS_Dyn = 0x20
 RF_PUT_MSG
0004359: ERROR: no ack
0004361: ERROR: no ack
0004363: ERROR: no ack
0004365: ERROR: no ack
0004367: RESTARTING
0005368: Password accepted
0005373: ERROR: no ack
0005375: ERROR: no ack
0005377: ERROR: no ack
0005382: Static config
 GPO = 0xBC
 MB_MODE = 0x01
0005384: Configuring GPO control - awake
0005471: Dynamic config
 IT_STS_Dyn = 0x20
 RF_PUT_MSG
0005473: Read mailbox
0005474: Sending CRC
0005475: Written to mailbox
0005631: Dynamic config
 IT_STS_Dyn = 0x40
 RF_GET_MSG
0005669: Dynamic config
 IT_STS_Dyn = 0x20
 RF_PUT_MSG
0005670: Read mailbox
0005671: Sending chained msg
0005675: Written to mailbox
0005743: Dynamic config
 IT_STS_Dyn = 0x40
 RF_GET_MSG
0005796: Dynamic config
 IT_STS_Dyn = 0x20
 RF_PUT_MSG
0005797: Sending unchained msg
0005798: Written to mailbox
0005862: Dynamic config
 IT_STS_Dyn = 0x40
 RF_GET_MSG
0007154: Dynamic config
 IT_STS_Dyn = 0x20
 RF_PUT_MSG
0007156: Sending CRC
0007157: Written to mailbox
0007302: Dynamic config
 IT_STS_Dyn = 0x40
 RF_GET_MSG
0007339: Dynamic config
 IT_STS_Dyn = 0x20
 RF_PUT_MSG
0007340: Read mailbox
0007341: Sending chained msg
0007348: Written to mailbox
0008444: Dynamic config
 IT_STS_Dyn = 0x40
 RF_GET_MSG
0008494: Dynamic config
 IT_STS_Dyn = 0x20
 RF_PUT_MSG
0008497: Written to mailbox
0008529: Dynamic config
 IT_STS_Dyn = 0x40
 RF_GET_MSG
0009845: Dynamic config
 IT_STS_Dyn = 0x20
 RF_PUT_MSG
0009849: Sending CRC
0009850: Written to mailbox
0010010: Dynamic config
 IT_STS_Dyn = 0x40
 RF_GET_MSG
0010049: Dynamic config
 IT_STS_Dyn = 0x20
 RF_PUT_MSG
0010050: Read mailbox
0010061: ERROR: no ack
0010063: ERROR: no ack
0010065: ERROR: no ack
0010067: Sending chained msg
0010070: Written to mailbox
0010155: Dynamic config
 IT_STS_Dyn = 0x40
 RF_GET_MSG
0010205: Dynamic config
 IT_STS_Dyn = 0x20
 RF_PUT_MSG
0010208: Written to mailbox
0010209: Written to mailbox
0010258: Dynamic config
 IT_STS_Dyn = 0x40
 RF_GET_MSG
0014153: Dynamic config
 IT_STS_Dyn = 0x08
 FIELD_FALLING
0014164: Dynamic config
 IT_STS_Dyn = 0x10
 FIELD_RISING
0014296: Dynamic config
 IT_STS_Dyn = 0x08
 FIELD_FALLING
0022735: ERROR: no ack

JL. Lebon · ‎2021-11-12

Hello Jack,

Sorry for my late answer, yesterday was bank holiday in my contry and thank you for the trace, it is interesting.

It rises several comments/questions:

to activate the fast transfer mode, it is required to set MB_EN bit 0 of MB_CTRL_Dyn to 1. The MB_MODE register is set to one just to allow activation of FTM, and then the MB_EN bit must be set to 1 to activate the FTM. I see nowhere is the trace the write in MB_CTRL_Dyn(MB_EN)=1. Is it done on the RF side ?
In line 3, I see that GPO=0x84. This means RF_INTERRUPT_EN=1 and GPO_EN=1. At this point, the RF_PUT_MSG interrupt is not enabled. However, I see on line 8 that IT_STS_Dyn=0x20, which means that RF_PUT_MSG interrupt has been raised. Does this mean that the GPO(RF_INTERRUPT_EN) bit has been set to one by the RF ?
Then on line 10, I guess this is where you start writing the mailbox ? It would be very interesting to read the content of MB_CTRL_Dyn between line 9 and line 10 to check that everything is OK for a write in the mailbox.

In a general way, when receiving the RF_PUT_MSG or RF_GET_MSG interrupt, I strongly recommend to read the MB_CTRL_Dyn register as the next action to check that all status bits are ok to read or write the Mailbox. MB_CTRL_Dyn purpose is to control the flow between I2C and RF, you can't just relay on IT_STS_Dyn for that.

Best regards.

JButc.1 · ‎2021-11-12

I can see why our log would be a bit confusing. It is quite bare bones.

To answer your questions:

Yes, the mailbox is enabled on the RF side.
The GPO is set to GPO_EN | RF_INTERRUPT_EN when in standby mode. This allows our mobile app to send the Manage GPO interrupt to wake the host. Then, in the log, line 6: 'Configuring GPO control - awake', sets the GPO register to GPO_EN | GPO_INT_EN | RF_PUT_MSG_EN | RF_GET_MSG_EN | FIELD_CHANGE_EN which is the setting for FTM.
Line 7 is where the RF side has enabled the mailbox, then sent the first message to the mailbox. I will try doing a read of MB_CTRL_Dyn at this point as you suggest.

Since sending that log, I've realised that the NACKs we are receiving are caused by us sending an error response that's not being accepted. The host is not attempting to read the first message put by RF because a field in the FTM header - 'function' is not set to either idle or R2H (I realise this could be either an internal issue to our firmware or external from the tag or mobile app). After 500ms the host times out and sends the error frame and that results in the NACKs. The mobile app then also times out, then tries again. It just so seems to happen that the time it takes for everything to start working is about 6 seconds from that first message.

When forcing that function field to idle or R2H in the firmware, it seems to be reset to what looks like garbage whenever the RF side enables the mailbox and writes the first message. After 6 seconds everything returns to normal. The funny thing is if we power the unit on via button press the FTM works straight away. Possibly we're overlooking an effect of using the RF interrupt to power up the tag?

By the way the mobile app is using the ST25SDK001 for android if that helps.

Thank you!

JL. Lebon · ‎2021-11-16

Hello,

I'm not sure I understand what you are saying about "us sending an error response that's not being accepted".

Have you tried to use the MB_CTRL_Dyn register to control the flow between I2C and RF as suggested ?

Best regards.