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.

[Ulysses HERNIOSUS · Accepted solution]

Hi,

the mentioned NULL deref bug has been identified already and will be fixed in the next version. I think on our used test platform NULL/0 was a legitimate address.

If you find issues, you can either report them here or go through your contacts into ST sales representatives.

Best Regards, Ulysses