migrating from ST25R3911B to ST25R3916B, 15693-3 command gives framing error

[AIudi.1]

I'm migrating from ST25R3911B to ST25R3916B and i find that rfalTransceiveBlockingTxRx used with 3916B doesn't work with 15693-3 custom command. I get error=0x9 (framing error)

I'm using the addressed mode on 3911B and 3916B, the message buffer is the same, the tag is the same (NTAG5). The custom command format is: FLAG - CMD_CODE - MFG_CODE - UID - BLOCK_ADDR - BLOCK_NUMBER - CRC

FLAG is 0x22

CMD_CODE: 0xC0

MFG_CODE: 0x04

The same function used in a custom write operation (CMD_CODE 0xC1) works, and it works for all standard write and read commands called before the custom read register wich fails.

Thanks for any help

[Ulysses HERNIOSUS]

Hi,

source code indicates that framing error gets only triggered on a non-matching SOF. Maybe tag is replying too early the deaf time/mrt/fdt_listen on 3911 is more relaxed in 3911. Could you try decreasing FDTListen? Easiest to decrease RFAL_FDT_LISTEN_NFCV_POLLER by multiples of 64.

Best Regards, Ulysses

[AIudi.1]

Thanks Ulysses,

i did a brute-force test decresing fwt from RFAL_NFCV_FDT_MAX (271156) to 0, by 64 decrements. I'v got this result:

• fwt from 271156 to 4596 --> err = 9 (framing error)
• fwt from 4532 to 4340 --> err = 4 (timeout)
• fwt from 4276 to 52 --> err = 3 (parameter error)

on 3911B i use the default fwt parameter from the library ( rfalConv64fcTo1fc( ISO15693_FWT * 4 ); ) and it works.

with low values for FWT i get parameters error, but buffer transferred are the same.

I add a txt file with code for both cases, logs and some comments.

Best Regards

Antonio

[Ulysses HERNIOSUS]

Hi,

you were adjusting the wrong time/define. The one you were adjusting is for adjusting the max time after which a tag is not allowed to respond anymore. The one I was referring is about the minimal time. As the framing error happens only on SOF I am suspecting an issue in this minimal time (MRT of ST25R3911B).

Regards, Ulysses

[Ulysses HERNIOSUS]

Hi Antonio,

Looking at the received pattern it seems not a simple shift or damaged SOF:

3f cf cc cc cc 30 cf
11111100111100110011001100110011001100110000110011110011

The sequence should have a SOF symbol of 11101 followed by only 01 or 10 symbols until EOF.

Did you by mistake set the two subcarriers request flag?

Otherwise you really need to look into the RF:

Field probe (connect the probe to the ground wire to build a small loop and put it between tag and reader antenna) and probe the CSI/CSO pins using described observation modes.

Which tag are you using? Something off the shelf? Similar for the reader: Is it one of our reader boards or something you did?

Best Regards, Ulysses

[AIudi.1]

Hi Ulysses,

logging flags i get 0x12 or 0x22 for selected or addressed mode, I'll check if somewhere the bit 1 of the flab byte is set inadvertly.

I'm using commercial tag (NTAG 5 Switch from NXP), X-NUCLEO-NFC08A for 3916B transceiver and X-NUCLEO-NFC05A for 3911B transviver. Each transceiver is connected to a NUCLEO Board (G431RB for NFC05A and L476RG for NFC08A).

I hope sincerely to solve without debugging RF layer.

Best Regards,

Antonio

[Ulysses HERNIOSUS]

Hi Antonio,

at this stage everything hints on RF layer. Maybe you inadvertently messed up receiver settings (maybe analog configs) or something. But for this best way to go is Logic analyzer + digital observation. I could analyze the trace to see if there are unwanted register settings. And we would also see if strange things are coming from the tag/receiver.

For the two subcarrier hypothesis you could also check the first few actual bytes being written into FIFO and compare it to good 16B case or even 3911 case.

Best Regards, Ulysses

[Brian TIDAL]

Hi Antonio,

your issue is due to the custom command being treated as an ST proprietary fast command in rfalNfcvPollerTransceiveReq (C0h is ST Fast Read Single Block). When such a fast command is processed, a rfalSetBitRate command is done to move to 53 kbps whereas your tag replies at normal speed.

You can modify rfalNfcvPollerTransceiveReq to check the ST manufacturer id (0x02) when processing the ST fast command to avoid changing the bit rate for non ST commands.

This issue will be reported internally.

Rgds

BT

Rgds

BT

[AIudi.1]

Hi Brian,

i've added another condition on /* Check if the command is an ST's Fast command */ if statement to check if param == RFAL_NFCV_PARAM_SKIP (in my case, I use param=MFG_CODE for custom commands).

Now it works.

Thank You for support.

Best regards,

Antnio