T2T Emulation Response Failure

[LltWc]

I'm working on emulating a T2T with my device. It successfully makes it through automatic anticollision, then starts looking for commands. When I see 0x30 0x00, I go ahead and send the first 16 bytes, but the reader does not react or show the read data.

Right now I'm thinking that I'm transmitting wrong while in Listen Mode. The RFAL never does T2T emulation, so I don't have an example there. Right now, when I see a 0x30 command, I do the following:

Send command CLEAR FIFO

Set Num Tx Bytes 1 to the MSB

Set Num Tx Bytes 2 mask 0xF8 to the LSB

Write the data to the FIFO

Send command TX WITH CRC

Is there a different way to do it in Listen Mode? With T2T Emulation the chip's field will never be on, but I don't see a way to explicitly modulate a response. The first 16 bytes are shown above, with the CC 0xE1 0x10 0x3F 0x0F. I do also have an empty NDEF TLV and the Terminator TLV, but no memory regions beyond the first 4 blocks are attempted to be read.

Also - I couldn't find any information on the INT2 byte after the second BCC, so I copied the 0x48 I've seen on NTAGs. What does that byte represent?

[Ulysses HERNIOSUS]

Hi LltWc,

honestly, don't know with this macroscopic view. You need to debug by:

1. Some NFC reader device (e.g. the mentioned) debug tabs which allow you to 
   • Verify all the state changes and FWT timings inside your tag implementation
   • Assess the operating volume - look for holes, etc.
2. Trace the communication with the phone (NFC sniff and/or Logic analyzer of ST25R comm).
   • Identify sequences which are not implemented in you software
   • See timing which may not have been fulfilled.

For commands not understood I would typically mute (i.e. not send a response). For commands per T2T protocols I would then return a 4bit NACK (e.g. the mentioned 0000).

Could be that you are not handling the Removal Procedure of the phone correctly. I would assume a HLTA->WUPA sequence. With the HLTA your software needs to issue the GOTO_SLEEP direct command. But also many other things which might happen. With the little information you are essentially blind.

Ulysses

[LltWc]

Understood, thanks. I improved some of the state transitions and resolved a hardware issue that was affecting the antenna range and now I can read pretty consistently with a Pixel 6a, but not with a Galaxy Fold or iPhone.

Also, a few questions on the ST25R3916 Discovery GUI, as the user manual doesn't go into detail:

• In the "Polling" tab, my device does not show up as a found tag. However, if I uncheck "Ignore tag fragments", it does show up. What is a tag fragment, and how does it differ from a full tag?
• In the "ISO 14443A" tab, when I send a REQA, it responds "no anticollision, ATQA: 0044, REQA[NotSupported]". Is this saying that anticollision does not occur despite getting the ATQA?
• In the "NFC Type 2" tab, I also get a "NotSupported" error. What does that mean specifically?

[Ulysses HERNIOSUS · Accepted solution]

Hi,

Inside the ATQA there are fields where a tag should indicate if bitwise anticollision is supported. I think you swapped the bytes in your ATQA, should be 4400, the 44h should be transmitted first.

So it is showing it as a tag fragment as no UID could be received.

BR, Ulysses

[LltWc]

Well, this is embarrassing, but that was it. I messed around with ATQA order when I was initially populating PT_MEM because I wasn't sure which went first, but I had left it alone since then.

Now it works with all three test phones: Pixel 6a, Galaxy Fold4, iPhone 14. (Flipper Zero seems to break something, but that's likely because it doesn't respect the tag information as part of anticollision since it's just a hobbyist device.)

Question on the documentation, then. The NFC Forum Digital Protocol specifies Byte 1 of the SENS_RES/ATQA as the one with size (0x44), and Byte 2 as T1T stuff (0x00). The ST25R3916 datasheet specifies that the SENS_RES is bytes 10 and 11, but in the order [2:1]. I interpreted this as meaning 0x00 goes first, then 0x44. Is that the incorrect interpretation, or is the datasheet wrong?

[Ulysses HERNIOSUS]

Hi,

I think no order swap was intended in the text here and it just goes naturally out: Byte 10 being the first ATQA byte and byte 11 being the second ATQA byte. 

I admit that this detail is not well written on the doc.

BR, Ulysses