NFC "tag_reader" sample fails to read type 2 tags

[tknapstad]

I have set up an nRF52840-DK with the X-NUCLEO-NFC05A1 expansion board and flashed the NFC tag_reader sample. The application can read an ISO 14443-4 Type 4 tag just fine, but ISO 14443-3A tags seem to consistently fail with a ST25R3911B_NFCA_ERR_CRC error begin passed to the transfer_completed callback function. I have tried with both a Mifare Classic 1k and an NTAG216 which are read just fine by a mobile phone. 

I also tried upgrading from nRF Connect SDK 1.9.1 to 2.1.0, but with the same results. Any ideas on how to fix this?

Console output from NTAG216 tag:

Anticollision: 0x44 Platform: 0x0.
Tag info, type: 0.
Type 2 Tag.
NFC Transfer error: -1.

Console output from Mifare Classic tag:

Anticollision: 0x4 Platform: 0x0.
Tag info, type: 0.
Type 2 Tag.
NFC Transfer error: -1.

[Edvin]

Hello,

Is the X-NUCLEO-NFC05A1 expansion board supposed to work with the NTAG216 and Mifare Classic tag? Are you sure that they aren't doing something proprietary?

The return value from the NFC transfer error: -1. is just a return value from the tag reader (which communicates via SPI (not sure). It is not using the NFC on the nRF52840 (as you are probably aware). 

So if the nucleo shield claims to support ISO 14443-3A, but that is not the case, then you need to check with the manufacturer of the shield. 

Best regards,

Edvin

[tknapstad]

[The Mifare tag was using the Mifare dataformat, so let's just disregard that]

The NTAG216 is a fully compliant Type 2 tag, so that should be readable by the Nordic middleware for the  ST25R3911B NFC reader as documented here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/nfc/tag_reader/README.html

(The ST25R3911B should definitely support this as far as I can tell)

When reading the tag with the "NFC Tools" Android app on a mobile phone, it reads the data in NFC Forum Type 2 format as shown in the screenshot below


The anticollision request returns 0x44 just as in the tag_reader sample.

The -1 return value stems from the static helper function rx_error_check in nrf/lib/st25r3911b/st25r3911b_nfca.c:

// From st25r3911b_nfca.h

/**
 * @defgroup st25r3911b_error NFC-A protocol and transmission error.
 * @{
 */
#define ST25R3911B_NFCA_ERR_CRC 1
#define ST25R3911B_NFCA_ERR_PARITY 2
#define ST25R3911B_NFCA_ERR_FRAMING 3
#define ST25R3911B_NFCA_ERR_SOFT_FRAMING 4
#define ST25R3911B_NFCA_ERR_HARD_FRAMING 5
#define ST25R3911B_NFCA_ERR_LAST_BYTE_INCOMPLETE 6
#define ST25R3911B_NFCA_ERR_TRANSMISSION 7


// From st25r3911b_nfca.c

static void rx_error_check(uint32_t irq)
{
	if (nfca.state.txrx != RX_STATE_START) {
		return;
	}

	if (irq & ST25R3911B_IRQ_MASK_ERR1) {
		nfca.transfer.error = -ST25R3911B_NFCA_ERR_SOFT_FRAMING;
	} else if (irq & ST25R3911B_IRQ_MASK_ERR2) {
		nfca.transfer.error = -ST25R3911B_NFCA_ERR_HARD_FRAMING;
	} else if (irq & ST25R3911B_IRQ_MASK_PAR) {
		nfca.transfer.error = -ST25R3911B_NFCA_ERR_PARITY;
	} else if (irq & ST25R3911B_IRQ_MASK_CRC) {
		nfca.transfer.error = -ST25R3911B_NFCA_ERR_CRC;
	} else {
		nfca.transfer.error = 0;
	}
}

The interrupt register in the ST25R3911B has been read over SPI here, and the CRC error bit is set, so -1 is eventually passed to the callback function transfer_completed in the tag_reader example code. 

I suspect there is either a problem with the tag_reader sample in the nRF Connect SDK or the Nordic middleware for the ST25R3911B here, but I'm not sure how I should proceed to debug this further.

[Edvin]

I think the CRC error bit comes from the CRC calculation on the tag reader itself. CRC errors can typically mean that some timing is a bit off on either the tag or the tag reader. 

If you suspect that the issue is with the middleware, you can either try the shield (X-NUCLEO-NFC05A1) with another application processor using different drivers, or you can start digging into where the irq passed into ex_error_check is generated, but I think you would find that the irq is coming from the SPI message from the shield to the nRF. 

I don't have an X-NUCLEO-NFC05A1 shield myself, and I don't have the tag that you are trying to scan, so I don't have any ways to replicate the issue you are seeing. Do you see where the irq is coming from? 

I see that rx_error_check() is called from irq_process(), where the irq is generated using st25r3911b_irq_read(). This function returns status, which is either coming from a "data" array.

The ST25R3911B_IRQ_MASK_CRC == 0x800000UL, so when st25r3911b_irq_read() should return something with this mask. Can you tell if the bit (see screenshot below) is coming from data[2]? If so, it would come from the SPI message, right?

BR,

Edvin

[cnc_freak]

Hello. I'm facing the same issue, trying to read a Tag 2 type tag.

Where is located the "ST25R3911B_IRQ_MASK_CRC == 0x800000UL".

Regards.

[Edvin]

Hello,

As the original question, this is a bit outside of Nordic Semiconductor's area. It is the tag reader that reports the CRC error. Perhaps there was a bad reception? Perhaps the tag reader has a bug, I don't know. I suggest you contact the manufacturer of the tag reader for follow up questions. 

BR,
Edvin