ST25R3916. Problem connecting with Google Pay on old Android phones

[RAvkh]

Our NFC reader, based on ST25R3916, works fine with Google Pay(modern Android phones), Apple Pay, Visa, Mastercard, Mir... 

But i’ve got the strange issue then interacting by ST25R3916 with old Android phones (Galaxy A6, Huawei P smart…).

Paying card application did not started with 6984 or 6F00 error code.

The same phones works fine with our another NFC-reader, based on TI TRF7970A chip (not emvco-certified).

APDU Log:

PPSE >00A404000E325041592E5359532E4444463031

<6F23840E325041592E5359532E4444463031A511BF0C0E610C4F07A00000000410108701019000

AID >00A4040007A0000000041010

<6F00

I’ve tried to use ST example project «STM32CubeExpansion_NFC6_V1.0.0\PollingTagDetect" + Nucleo board and got the same issue.

Can you help me?

[Ulysses HERNIOSUS]

Hi,

I am surprised that anything like that can depend on the used reader: 6F00/6984 are ISO 7816-4 error codes coming from the applet and are not related to the actual RF.

• 6984 : Error: Reference data not usable
• 6F00 : Error: No precise diagnosis

The only thing I could think of is a timing issue in the phone, i.e. that the applet is not started in time / correctly and then the android layer creates these APDU error codes. I would start analyzing by sniffing the complete RF communication and verify the exchanged frames are the same for 3916 and the TI solution.

I guess you can control both readers so you should also be able to log all the exchanged frames.

If you are absolutely sure that the exchanged frames are the same then I would place delays in the application code before sending Select PPSE / Select application.

Regards, Ulysses

[RAvkh]

Hello!

Can i use ST25R3916 as a NFC sniffer?

I can not find working example for NFC RX mode only.

I'm tried: rfalNfcDataExchangeStart( NULL, 0, &rxData, &rxLen, 0 ) to get RX, but without success.

[Ulysses HERNIOSUS]

Hi,

ST25R3911/16 are reader chips. As such you set the expected technology + bitrate before starting reception. The above mentioned rfalNfcDataExchangeStart() requires a previously detected and activated device. Using rfal lower layer (rfalStartTransceive()) you can start reception only but only for a given bitrate (except for bitrate detection mode which can only detect A106, F212 and F424 poller frames when using rfalListenStart()).

A real sniffer would decode all protocols and all roles (poller and listener) at the same time. The ST25R3911/16 are not built for such use cases.

There are some people in the community trying such things using transparent mode:

https://community.st.com/s/question/0D50X0000BiCmALSQ0/questions-about-configurations-of-st25r3916-for-transparent-mode-passiveactive-target-for-iso14443-type-ab-and-iso15693

https://community.st.com/s/question/0D50X00009XkaZ8SAJ/st25r3911b-transparent-mode-example

You may achieve something using these methods but don't expect same performance as for normal operation.

Regards, Ulysses

[RAvkh · Accepted solution]

Hello!

Problem was in additional 0x00 in AID APDU

[ben_hw_sw]

Hi,

I confirm that I have managed to use the st25r3916 as passive sniffer (even if it is not designed for that) and so far it work fine with NFC-A 106kbps for PICC and PCD.

So far it requires special configuration (in listen mode) with Observer special setting.

I'm doing other tests and will publish a full sniffer on https://github.com/hydrabus/hydrafw_hydranfc_shield_v2

You are welcome to support this open source development.

Best Regards,

Benjamin