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,

not sure about which INT2 and the BCC you are referring? Something in the manufacturer data? AFAIK this is not defined per T2T spec.

I see some chance that you are running into timing issues here. The Read command needs to be answered within 4.75ms. Maybe your logging is delaying too much.

From a first glimpse (without checking the full mem content) the rest looks fine. What is your counterpart here? Maybe as a first step you can verify your procedures using ST25R3911B-DISCO or STEVAL-25R3916B GUI and their debug tab. There you can send arbitrary frames and also put timings as per spec to see what the Poller actually sees. This way you can more easily discriminate:

1. No answer received
2. Late answer received.
3. Garbled answer received
4. Expected data received but then for some reason the mobile/full NDEF implementation doesn't like it.

BR, Ulysses

 

[LltWc]

 

Yes, I'm referring to the manufacturer data (which I have to figure out how to set myself). The INT2 name comes from this Infineon spec, Block 2 Byte 1. The T2T spec from the NFC Forum just lists it as Internal9 and doesn't specify how to set it. The BCCs are Internal3 and Internal8, the BCCs of the previous section of the UID. I do think those 16 bytes are fine though.

So far as I can tell, the timing is all good. The IRQ comes in within a millisecond of "LM respond" in the below screenshot at 15.009,033. Then we read, and the transmit process completes at 15.012,145.

I'm using a Flipper Zero (which uses an ST25R3916) and a phone. I have a NUCLEO-L476RG + X-NUCLEO-NFC08A1 set up and it will transition my device to ACTIVE, but I'm not seeing the 30 00 come in so that's what I'll work on now so that I can actually observe it happening.

Just to check, in passive target mode, I should still be using Command Transmit with CRC, right? Does the chip see that the mode is set to ISO-14443A passive target and then transmit using modulation rather than generating its own field? Is the sequence I detailed above correct to respond as a passive target?

[Ulysses HERNIOSUS]

Hi LltWc,

yes, as said, basic procedure looks fine - sending using FIFO + Transmit with CRC command. Not sure about the timing - the time stamps are not fully clear, when the PCD frame has been received, could be in the 4ms range. At such level also Logic analyzer traces with SPI+IRQ would help a lot. Potentially also observation mode tana=5 and observing TAD1/TAD2 or CSI/CSO.

BR, Ulysses