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

[LltWc]

Unfortunately the device is sufficiently packaged that looking at I2C would be a lot of trouble. If it ends up being the only option I'll do that.

I have an STEVAL-25R3916B on order, and I'm planning to switch to Type 4 Tag Emulation, since then at least I can follow the RFAL. The main struggle I'm facing now is that I just don't seem to be getting RXE interrupts when I would expect them. I would only in rare cases get a 30 00 command when presenting as a T2T, and then only after several scans with the Flipper Zero, it would say the device type was Mifare Ultralight, say it was 48 bytes, and show me only the first 16 (and never send a read request for 30 04 or anything else).

It still seems like there's something fundamentally wrong with how I have it set up to transition from automatic anticollision to user-handled IRQs, or there's something I'm missing about how to advertise the tag type, but I'm pretty sure I had the right ATQA and SAK.

[Ulysses HERNIOSUS]

Hi,

my bets go on timing issues, if you sometimes get the 30-00. I2C is slow and and in general we don't recommend it for RFAL using CE.

But I think in the end you will need to observe - SDA,SCL,INT at least.

BR, Ulysses

[LltWc]

That's a tough one then, we're all in on I2C at this point.

Does T4T offer less stringent timing requirements? I frequently see that the ST25R3916 enters ACTIVE and then very shortly after goes back to POWER_OFF according to the passive target display register. 

[Ulysses HERNIOSUS]

Hi LltWc,

Yes in T4T a tag will provide an FWI (Frame Waiting Time Integer). A tag can choose which value to set, typically we use 8 which should correspond to some 78ms. Then all data transfer in T4T is not time critical anymore. 

The RATS - ATS and maybe some DESELECT are still somewhat time-critical (5ms range).

Without I2C tracing, please make sure you get one of the NFC Debug tabs operational to send single frames with various time limits.

BR, Ulysses

[LltWc]

Got it, thanks. I've made some good progress on this, I didn't end up needing to implement T4T. When an Android phone is properly connected to the tag, it reads the data on it as expected using the NFC Tools app. The Flipper, for some reason, sends a bunch of non-T2T commands. From what I can tell, I should be responding with a 4-bit all-0s short frame for invalid commands, which I do, but the Flipper only moves on to the next command when I remove it and put it back into the field.

As far as the T2T I do have working - the main issue I'm seeing now is that the ST25R3916 rapidly transitions from POWER_OFF -> EON -> IDLE -> READY_L1 -> sometimes READY_L2 -> EOF -> POWER_OFF. It seems like it's not properly completing anticollision in most cases despite beginning it. It works most consistently when I have the coils very close and very lined up. I've also tried it with tags disabled in case that was messing up timing, and get the same result.

When the device is operating as a reader, it has a range of about 1cm. Should I be expecting the same range for tag emulation?

Additionally, are there more configurations than I'm seeing that would affect when the chip does/doesn't successfully complete anticollision? I set the peer field activation threshold to 150mV and the peer field deactivation threshold to 75mV to hopefully give it more bandwidth to stay alive, but that doesn't seem to have helped. As in the RFAL, I have Antenna Tuning 1 set to 0x00 and Antenna Tuning 2 set to 0xFF, as well as overshoot and undershoot protection disabled.

[LltWc]

Also - the NUCLEO-L476RG + X-NUCLEO-NFC08A1 can read from 1-2cm so it definitely looks like our device's antenna setup is sufficient. Is there something I'm missing as far as communicating with a phone?