ST25R3911B ERROR FRAMING in reception

[PDe G.19]

Hi,

i'm trying to perform a communication with an ISO14443-A smart card using the X-NUCLEO-NFC06A1 expansion board. The smart card supports the following bit rate: 106, 212, 424 and 848 kbit/s according to the ATS received. If i negotiate with the smart card a 848 kbit/s bit rate both in transmission and reception and i try to send an APDU, the rfal library returns an ERROR FRAMING in reception. In particular the error is returned by rfalTransceiveRx() method implemented in rfal_rfst25r3911.c file:

 case RFAL_TXRX_STATE_RX_WAIT_RXE:
 
 irqs = st25r3911GetInterrupt( (ST25R3911_IRQ_MASK_RXE | ST25R3911_IRQ_MASK_FWL | ST25R3911_IRQ_MASK_EOF) );
 if( irqs == ST25R3911_IRQ_MASK_NONE )
 {
 /*******************************************************************************/
 /* REMARK: Silicon workaround ST25R3911B Errata #1.1 */
 /* ST25R3911 may indicate RXS without RXE afterwards, this happens rarely on */
 /* corrupted frames. */
 /* SW timer is used to timeout upon a missing RXE */
 if( rfalTimerisExpired( gRFAL.tmr.RXE ) )
 {
 gRFAL.TxRx.status = ERR_FRAMING;
 gRFAL.TxRx.state = RFAL_TXRX_STATE_RX_FAIL;
 }
 /*******************************************************************************/
 
 break; /* No interrupt to process */
 }

It seems that the chip does not receive the end of frame and a timer interrupt occurs. If, instead, the bit rate is set to 424 kbit/s no problem occurs. Is there someone could explain me why this happens? Moreover, where i can find the ST25R3911B Errata #1.1?

Thanks in advance. Best regards,

Pierluigi

[Ulysses HERNIOSUS]

Hi Pierluigi,

• regarding the errata sheet: Please contact your local FAE
• I assume you are talking about the X-NUCLEO-NFC05A1?
• The aforementioned errata item would not happen systematically in real-world conditions but be sporadic:
  • Do you observe this behavior sporadically / only in certain positions inside the operating volume or always?
  • Which MCU are you using? Did you port it on your own? Potentially some protection is missing which makes the RXE bit disappear for this software block due to changed timing.
  • Can you provide a logic analyzer trace of this issue (SPI + IRQ)?

Regards, Ulysses

[PDe G.19]

Hi Ulysses,

thanks for your answer.

• Yes, i'm talking about X-NUCLEO-NFC05A1
• I observe this errata item using some ISO 14443 Type A smart cards and only when i set DSI and DRI parameters to 848 kb/s. When, instead, i set those parameters to 424 kb/s communication is performed correctly.
• I'm using an STM32L053R8 MCU. What kind of protection are you referring to?
• I can't provide a logic analyzer trace unfortunately.

I tried also to change the SPI prescaler thinking that the MCU could not observe the IRQ signal, but nothing has changed.

Regards

Pierluigi

[Ulysses HERNIOSUS]

Hi Pierluigi,

I would like to analyze this further. I do have an STM32L053 Nucleo-64 and of course also an X-NUCLEO-NFC05A1.

Can you please do the following things:

1. Which exact card are you using in your tests?
2. I assume you plug the X-NUCLEO-NFC05A1 into the STM32L053 Nucleo-64. Correct? Any other HW modifications?
3. Can you please send me your hex/bin file?
4. Can you send me your complete project?

Regards, Ulysses

P.S.: You can can also send this stuff via PM

[PDe G.19]

1. i'm using the Italian identity card
2. yes. No other HW modifications
3. i'm sorry but i can't send you neither the complete project nor the hex file

[Ulysses HERNIOSUS]

Hi Pierluigi,

this makes it difficult for me to analyze. I did now take the ST25R3911B-DISCO and verified with a a Desfire card that 848 is operational: ISO14443A tab, activate to 848 using PPS, going to Debug tab and press send command returns some APDU error code (6700).

Then I did load the ST25R3911B-DISCO fw on X-NUCLEO-NFC05A1+ STM32L476 Nucleo-64 + USB cable attached to the proper pins: The Desfire card can again be read @848.

Don't know what more I could do to analyze your issues.

Regards, Ulysses

[PDe G.19]

Hi Ulysses,

I'm sorry but I'm working on a company project and i am not allowed to provide project code or .hex file.

Anyway, I can provide you the SPI initialization as well as the steps performed for the ST25R3911B initialization and smart card activation.

SPI CONFIGURATION

static void MX_SPI1_Init(void)
{
 /* SPI1 parameter configuration*/
 hspi1.Instance = SPI1;
 hspi1.Init.Mode = SPI_MODE_MASTER;
 hspi1.Init.Direction = SPI_DIRECTION_2LINES;
 hspi1.Init.DataSize = SPI_DATASIZE_8BIT;
 hspi1.Init.CLKPolarity = SPI_POLARITY_LOW;
 hspi1.Init.CLKPhase = SPI_PHASE_2EDGE;
 hspi1.Init.NSS = SPI_NSS_SOFT;
 hspi1.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_16;
 hspi1.Init.FirstBit = SPI_FIRSTBIT_MSB;
 hspi1.Init.TIMode = SPI_TIMODE_DISABLE;
 hspi1.Init.CRCCalculation = SPI_CRCCALCULATION_DISABLE;
 hspi1.Init.CRCPolynomial = 7;
 if (HAL_SPI_Init(&hspi1) != HAL_OK)
 {
 Error_Handler();
 }
}

After SPI initialization I make the following call to initialize the rfal and to perform antenna calibration:

• rfalAnalogConfigInitialize()
• rfalInitialize()
• rfalCalibrate();

When a ISO 14443 A smart card is put in the field, first I perform the anticollision and then i call the proper rfal routine for the activation sequence as follows:

rfalIsoDepPollAHandleActivation(ISO14443A_RTAS_FSDI_256, RFAL_ISODEP_NO_DID, RFAL_BR_848, &isoDepDev);

Once activated, I try to send an APDU to the card in the following way:

iso14443TransmitAndReceive(&APDU, sizeof(APDU), &rxBuff, sizeof(rxBuff), &actrxlength, isoDepDev.FWT);

At this point RFAL returns ERR_FRAMING.

Reguards, Pierluigi

[Ulysses HERNIOSUS]

Hi Pierluigi,

I fear I have done what I can do under the circumstances. If you cannot provide me at least a binary file - best the source - I cannot give you meaningful recommendations. My experiments using ST25R3911B-DISCO essentially perform the same steps as you show above. Maybe you could strip your project of your IP and only leave the above sequence with a dummy APDU showing the behavior.

The behavior can be related to many things:

• Memory corruption
• Locking corruption
• Race condition
• Analog issue of the card
• ....

Otherwise you could go through official support channels and get up an NDA with ST and possibly then share your project with ST.

Regards, Ulysses

[Ulysses HERNIOSUS]

Hi Pierluigi,

I have one idea what it could be, would somehow fit to a an interrupt being lost. We have discovered this fundamental problem in a different project.

Can you please try to change the locking inside platform.h:

extern uint8_t globalCommProtectCnt;
#define platformProtectST25R391xComm() do{ globalCommProtectCnt++; __DSB();NVIC_DisableIRQ(EXTI0_IRQn);__DSB();__ISB();}while(0) 
#define platformUnprotectST25R391xComm() do{ if (--globalCommProtectCnt==0) {NVIC_EnableIRQ(EXTI0_IRQn);} }while(0)
 
#define platformProtectST25R391xIrqStatus() platformProtectST25R391xComm()
#define platformUnprotectST25R391xIrqStatus() platformUnprotectST25R391xComm()

and in e.g. main.c:

uint8_t globalCommProtectCnt = 0;

Background of this fix is that shortly after NVIC_DisableIRQ() the ISR can still execute. Compare below:

https://mcuoneclipse.com/2015/10/16/nvic-disabling-interrupts-on-arm-cortex-m-and-the-need-for-a-memory-barrier-instruction/

Regards, Ulysses

[PDe G.19]

Hi Ulysses,

I have changed the locking inside platform.h as you said, but I still have the same behavior.

A strange thing is that I have used another ISO14443 A smart card that supports 848 kb/s bit rate and the communication is performed correctly. I think the problem is with the electronic passports.

Regards, Pierluigi

[Ulysses HERNIOSUS]

Summary of the communication in private channel:

Issue disappears when going to optimization level -O3. At high bitrates it is also advisable to increase SPI speed to e.g. 4MHz.

[EBadi.2]

I have the same issue, but I don't know how to change optimization level to -O3 as you say.

[Ulysses HERNIOSUS]

Hi EBadi.2,

which MCU + toolchain are you using?

Typically you need to go to Options/Properties of your build target and look around in the C/C++ settings. As example I attach where to find in STM32CubeIDE.

Best Regards, Ulysses