2023-03-24 09:00 AM
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
Solved! Go to Solution.
2023-04-03 07:21 AM
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
2023-03-27 02:05 AM
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
2023-03-27 08:25 AM
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:
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
2023-03-28 01:02 AM
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
2023-03-28 03:40 AM
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
2023-03-28 04:33 AM
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:
Best Regards, Ulysses
2023-03-28 08:47 AM
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
2023-03-29 12:58 AM
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:
Best Regards, Ulysses
2023-03-30 08:23 AM
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
2023-03-31 02:53 AM
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