ST25R3920 T2T emulation Ack response

[vk5]

Hi,

I am using a ST25R3920 to emulate a type 2 tag. I have got the Read part working and I am able to send 16 bytes of data in response to 0x30 and confirm the data on a phone. But when the phone tries to write data using 0xA2, I am unable to send the 4 bit Ack (0xA) response that is acceptable for the phone which throws a write error. On probing the modulation using an oscilloscope, I noticed that the ST25 is sending

start 0101 0000 parity 

instead of

start 0101 parity

Here is my send sequence:

Clear FIFO

Set ntx = 0, nbtx = 4 (to send only 4 bits)

Load FIFO with 0xA

Transmit without CRC

Is it possible to send 4 bit frames in card emulation mode with this chip to support type 2 communication?

[Ulysses HERNIOSUS]

Hi,

Please try using no_tx_par=1, even though footnote says differently. This option was not fully verified but you have a good chance that it works well for your use case.

If you run into issues with it, then please let me also know.

BR, Ulysses

[vk5]

Hi @Ulysses HERNIOSUS 

I have already tried no_tx_par=1 without any success, still sends 8 bits. Since stream mode is also not supported in card emulation, is there any other option or is the chip not capable of sending 4 bit frames?

[Ulysses HERNIOSUS]

Hi,

I know for sure that ST25R3918 is capable of doing these 4 bit responses. ST25R3920 is using same logic and is identical in this respect. Or are you using ST25R3920B?

I have some traces showing r05h:0x80, r22h:0x00, r23h:0x04, FIFO getting 0xFA and transmission using C5 causing 4 bits being sent.

BR, Ulysses

[vk5]

I am using 3920, not the B. Are your traces from reader or card emulation mode, because I have seen 4 bit frames in reader mode.

Here is my initial configuration, in case I am missing something:

Set default

REG_OP_CONTROL = en | rx_en | en_fd_auto_efd

REG_MODE = targ | om_targ_nfca | nfc_ar_off

REG_PASSIVE_TARGET = 0

REG_AUX = nfc_id_7bytes

Load PT_Memory

Go to sense

[Ulysses HERNIOSUS]

Hi,

the traces I am referring are from CE mode. In these the ST25R3918 emulates a T2T including NDEF read-out and everything. These 4-bit responses are then issued once the pta_state has moved to ACTIVE/ACTIVE*. 

I recommend to start with such a scenario - perform the Anticollision using automatic responses (d_106_ac_a=0) and then perform commands for exchanging 4 bit responses.

Ulysses

[vk5]

Hi @Ulysses HERNIOSUS 

I was using the automatic anti collision and once the tag reached ACTIVE state, the reader sends a write command and the tag sends a 4-bit 0xA in response. The reader in this case is also a ST25R3920 and it generates interrupts for hard framing error and no response timeout after a start of receive. It never moves to end of receive when the tag tries to send a 4-bit frame using TX without CRC. Since the oscope confirmed that the tag is sending 8 bits instead of 4 bits, the reader times out expecting the CRC?

[Brian TIDAL]

Hi,

The ST25R3920 supports T3T and T4T card emulation. T2T card emulation is not an officially supported feature.

The following is a trace from the logic analyzer, showing a 4-bit acknowledgment being sent in card emulation mode:

Some devices, such as the Flipper Zero, emulate T2T tags. Refer to the Flipper Zero firmware source code for more details.

Rgds

BT

 

[vk5]

Hi @Brian TIDAL 

Thanks for pointing to the Flipper Zero code. It looks like it uses transparent mode to send 4 bit short frames.

I am sending the same sequence of commands you have shown in your logic analyzer trace. But the chip sends 8 bits instead of 4. Do you have a trace of the actual load modulated signal or the data received at the reader end to confirm it actually sends 4 bits?

If T2T is not officially supported, does it mean the 3920 is not capable of sending 4 bit frames except in transparent mode?

[Ulysses HERNIOSUS]

Hi,

I had a chat with Brian as well: We know that chip is able to send 4bit ACK/NACK and we are using it in one of our dedicated demos to emulate a T2T. It is not an official feature and there might be issues in some corner cases - maybe you are running into one. 

Can you please share a scope shot of the modulation, that you are seeing, please?

In our opinion it would be best if you would have a working reference. We will try to work on a small proof showing such frames work but this may take a few days. We were considering such based on ST25NFC Lib, so X-CUBE-NFC06 + NUCLEO-L474. Is this something you have at hand? If not, please share what you have.

BR, Ulysses

[vk5]

Hi @Ulysses HERNIOSUS 

Here is the scope shot from when I send the commands before anti collision sequence. This shows 1 0101 0000 1

This one is from after anti collision once the state is ACTIVE and write req is received. This is the same set of commands but for some reason it is stuck sending repeated zeroes

I can confirm that in response to the write req, if I send TX with CRC, there are no repeated zeros and 3 bytes are being sent and received correctly on the reader side

Unfortunately I don't have any ST25R39xx dev boards. The only STM board I have is the X-NUCLEO-LPM01A. I think if you are able to confirm the 4 bit ACK with your setup, then I will adapt your sample code to my hardware for testing.

 

[vk5]

@Ulysses HERNIOSUS 

I think I figured out the issue. If automatic anti-collision (d_106_ac_a) is disabled before sending, then only the 4 bits are sent as expected. Maybe this was supposed to be disabled when the tag reaches active state? I apologize if I had missed this in the RFAL.

Thanks for your help!

[Ulysses HERNIOSUS]

Hi,

yes RFAL disables automatic responses in RFAL_LM_STATE_READY_F. No need to apologize, we were also not aware that 4 bit responses are depending on d_106_ac_a. It was logical for us to disable automatic responses in this state and we never tried without.

BR, Ulrich