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

[AIudi.1]

Thank You Ulysses,

i see in rfal_rfst25r3916.c

#define RFAL_ST25R3916_MRT_MAX_1FC   rfalConv64fcTo1fc( 0x00FFU )         /*!< Max MRT steps in 1fc (0x00FF steps of 64/fc  => 0x00FF * 4.72us = 1.2ms )   */

#define RFAL_ST25R3916_MRT_MIN_1FC   rfalConv64fcTo1fc( 0x0001U/*0x0004U*/ )         /*!< Min MRT steps in 1fc ( 0<=mrt<=4 ; 4 (64/fc) => 0x0004 * 4.72us = 18.88us )  */

I've changed the RFAL_ST25R3916_MRT_MIN_1FC from 0x04 to 0x01 but it doesn't affect the result, i still get framing error

I've seen that FDT (for nfcV) is set by rfalSetFDTListen( RFAL_FDT_LISTEN_NFCV_POLLER ); in rfalNfcvPollerInitialize.

I've also checked that RFAL_FDT_LISTEN_NFCV_POLLER is defined in rfal_rf.h

#define  RFAL_FDT_LISTEN_NFCV_POLLER    4192U  /*4310U AI */  /*!< FDTV,LISTEN,MIN t1 min    Digital 2.1 B.5 ; ISO15693-3 2009 9.1                     */

the original value is 4310 (even if iso 15693-3 specify 4320/fc) and i've changed it to 4192, this value comes from rfal_rf.h used in the sw with st25r3616 where the Custom read operation works fine.

Anyway changing all theese defines seems to have no effect because in rfalStartTransceive() the minimum FDT time is set by:

st25r3916WriteRegister( ST25R3916_REG_MASK_RX_TIMER, (uint8_t)rfalConv1fcTo64fc( (FxTAdj > gRFAL.timings.FDTListen) ? RFAL_ST25R3916_MRT_MIN_1FC : (gRFAL.timings.FDTListen - FxTAdj) ) );

this code , in my case, writes 63 (decimal) in MRT register. I tried to set 1 in MRT but it doesn't work.

NOTE 1: MRT register is laoded with 63 each time i try to read or write single register and it works always but i get error only if I try to read registers with custom command (custom write instead works). 

NOTE 2: the same code with ST25R3911 load MRT register with 64, i tried to change 63 to 64 but it doesn't work.

Regards, Antonio

[Ulysses HERNIOSUS]

Hi Antonio,

the flow of value should be like this:

rfalSetFDTListen( RFAL_FDT_LISTEN_NFCV_POLLER ); // -> enters gRFAL.timings.FDTListen

to

st25r3916WriteRegister( ST25R3916_REG_MASK_RX_TIMER, (uint8_t)rfalConv1fcTo64fc( (FxTAdj > gRFAL.timings.FDTListen) ? RFAL_ST25R3916_MRT_MIN_1FC : (gRFAL.timings.FDTListen - FxTAdj) ) );

which should give (4310 - 64 - 64 ) / 64 = 65.

Reducing RFAL_FDT_LISTEN_NFCV_POLLER should have an effect on actual MRT register value. Please verify.

If the issue appears anyhow then we need to debug into the received bytes:

• Set rfalSetObsvMode(0x0a, 0x0b)
• Activate the "#if 0" "Debugging Code:" sequences in rfal_rfst25r3916.c
• Connect Logica Analyzer to SPI + IRQ + CSI + CSO

Best Regards, Ulysses

[AIudi.1]

Hi Ulysses,

i've did severa trials reducing RFAL_FDT_LISTEN_NFCV_POLLER to 100h but it doesn't work.

I call rfalSetObsvMode after rfalInitialize(), then i replace all #if 0 with #if 1 in rfal_rfst25r3916.c.

I connected my scope to SPI and IRQ and stepping into the code to check SPI singals.

I've captured the source for ERR_FRAMING inside rfalIso15693VICCDecode where inBuff[0] is 0x3F but it shold be 0x17

As You suspected, the problem is the SOF, but i've used very little values for FDT, how can i solve?

Regards, Antonio

[Ulysses HERNIOSUS]

Hi Antonio,

0x3f would indicate that the tag is not doing a correct SOF (omitting the subcarrier pause: continued subcarrier). You could try making the rfalIso15693VICCDecode() more tolerant with respect to SOF but it would be good to understand the root cause:

1. Does this happen in all positions of the operating volume?
2. Does the NTAG5 have and use the boost feature?
3. Look into the signals on CSI/CSO (first step digital as indicated above) and second step also analog using other observation modes together with a field probe.

Best Regards, Ulysses

[AIudi.1]

Hi Ulysses,

the problem happens in any position, i'm actually working with tag very close to transceiver antenna.

The tag shouldn't have boost feature (it is not specified in the datasheet) anyway the same tag works with 3911B.

I did a signal and register compare between 3911B (the reference) and 3916B (where i have the fault)

I both cases i triggered the scope to trace the byte transfer before st25r3916ReadFifo called by rfalTransceiveBlockingRx, immediately before rfalIso15693VICCDecode (where SOF is processed)

This is the scope trace with 3911B with SOF=0xb7 OK.

and this is the buffer (same byte sequence decoded by the scope OK)

This is the scope trace with 3916B with SOF=0x3f FAIL

and this is the buffer (same byte sequence decoded by the scope FAIL)

You can observe the the number of bytes written when reading from the fifo is higher than the 3911B case.

Just to have a reference 3916B when it is working, i did the same trace with a standard read command rfalNfcvPollerReadSingleBlock from block address 2. I called the function just before the point where the custom read fails.

The buffer start with the right SOF

Any suggestion?

Note: the IRQ is not displayed because the scope have 4 ch, anyway i've checked, it should be ok.

Regards, Antonio

[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