Right way to ignore received CRC in ST25R3916 with RFAL

[OliM]

I am expecting an answer from an ISO14443-2 Tag with no CRC set, so I want to disable that check. Currently I am doing a rfalTransceive with the following flags

( (uint32_t)RFAL_TXRX_FLAGS_CRC_TX_AUTO | (uint32_t)RFAL_TXRX_FLAGS_NFCIP1_OFF | (uint32_t)RFAL_TXRX_FLAGS_AGC_ON | (uint32_t)RFAL_TXRX_FLAGS_PAR_TX_AUTO | (uint32_t)RFAL_TXRX_FLAGS_NFCV_FLAG_AUTO \

            | (uint32_t)RFAL_TXRX_FLAGS_CRC_RX_MANUAL | (uint32_t)RFAL_TXRX_FLAGS_CRC_RX_KEEP | (uint32_t)RFAL_TXRX_FLAGS_PAR_RX_REMV)

As a result I get a return value of ERR_CRC but also the expected length and data inside my provided response Memory. Is this expected behavior and I should just ignore the error code or is there a different flag I should use?

[Ulysses HERNIOSUS]

Hi,

not sure, no ERR_CRC should be triggered. Which RFAL version are you using, which demo board and could you share some more of your demo code, not just the flags?

Best Regards, Ulysses

[OliM]

Hi,

I am using an X-NUCELAO-NFC06A1 on an STM32L562E-DK with RFAL version 2.6.0. After an NFC-A target without ISO-DEP support was detected i run the following code:

#define NO_RX_CRC_FLAGS ( (uint32_t)RFAL_TXRX_FLAGS_CRC_TX_AUTO | (uint32_t)RFAL_TXRX_FLAGS_NFCIP1_OFF | (uint32_t)RFAL_TXRX_FLAGS_AGC_ON | (uint32_t)RFAL_TXRX_FLAGS_PAR_TX_AUTO \
 | (uint32_t)RFAL_TXRX_FLAGS_CRC_RX_MANUAL | (uint32_t)RFAL_TXRX_FLAGS_CRC_RX_KEEP | (uint32_t)RFAL_TXRX_FLAGS_PAR_RX_REMV )
...
const uint8_t AuthKeyA[] = {0x60, 0x00};
uint8_t RxBuff[255] = {0};
uint16_t RcvLen = 0;
Err = rfalTransceiveBlockingTxRx((uint8_t*)AuthKeyA, sizeof(AuthKeyA), (uint8_t*)RxBuff, sizeof(RxBuff), &RcvLen, MFC_NO_RX_CRC_FLAGS, RFAL_1MS_IN_1FC);

As you might have guessed by now I will also have to do parity by hand afterwards, but I still don't get why there is an error message for the answer here.

[Ulysses HERNIOSUS]

Hi,

I have experience with RFAL_TXRX_FLAGS_PAR_RX_KEEP instead of RFAL_TXRX_FLAGS_PAR_RX_REMV. In that scenario no ERR_CRC gets signaled.

Could you do logic analyzer traces and check the value of the register 0x0a (Auxiliary Definition register).

Best Regards, Ulysses

[OliM]

I get the same ERR_CRC no matter whether I use RFAL_TXRX_FLAGS_PAR_RX_KEEP or RFAL_TXRX_FLAGS_PAR_RX_REMV.

I have no logic analyzer connected at the moment so all I could offer for register states are debug points inside RFAL.

[Ulysses HERNIOSUS]

Hi,

A logic analyzer trace will help so much more as there is also a possibility of looking at a porting artifact.

BR, Ulysses

[OliM]

I have to admit that it's not a priority for me right now since I can read both ISO and non ISO cards (MFC) completely and only get that return value in the specific case where I want to ignore CRC on receive but still generate the send CRC and parity by hardware.

On another note: What's the best place to report bugs in RFAL?

This one is quite obvious:

ReturnCode rfalWakeUpModeStart( const rfalWakeUpConfig *config )
{
 uint8_t aux;
 uint8_t reg;
 uint32_t irqs;
 
 /* Check if RFAL is not initialized */
 if( gRFAL.state < RFAL_STATE_INIT )
 {
 return ERR_WRONG_STATE;
 }
 
#ifdef ST25R3916B
 /* Check for not supported features */
 if( config->cap.enabled )
 {
 return ERR_NOTSUPP;
 }
 
 /* Set ST25R3916B Measure Tx delay */
 st25r3916WriteRegister(ST25R3916_REG_MEAS_TX_DELAY, ( st25r3916IsAATOn() ? RFAL_ST25R3916B_AAT_SETTLE : 0x00) );
#endif /* ST25R3916B */
 
 /* The Wake-Up procedure is explained in detail in Application Note: AN5320 */
 
 if( config == NULL )
 {
 gRFAL.wum.cfg.period = RFAL_WUM_PERIOD_200MS;
 gRFAL.wum.cfg.irqTout = false;

line15 accesses NULL when default config is selected on upper level.

That was the first thing I encountered when switching to ST25R3916B (on a self modified NFC06A1 board), but the CRC behavior remains the same as before.