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

[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

[AIudi.1]

Hi Ulysses,

Befor starting a time consuming debugging on RF i need to be quite sure to have checked as much as possible problems into software.

I used the example code from ST25NFC_Embedded_Lib_ST25R3916_1.4.0 (exampleRfalPoller.c) where i've modified exampleRfalPollerDataExchange() to execute standard read and write operatation (they works) and custom write and riead operations (write works, read doesn't).

custom read and write are just slightly modified wrappers of rfalNfcvPollerReadSingleBlock and rfalNfcvPollerWriteSingleBlock.

Here is the code of the rfalNfcvPollerReadSingleBlock and rfalNfcvPollerReadSingleBlockCustom:

ReturnCode rfalNfcvPollerReadSingleBlock( uint8_t flags, const uint8_t* uid, uint8_t blockNum, uint8_t* rxBuf, uint16_t rxBufLen, uint16_t *rcvLen )
{
    uint8_t bn;
 
    bn = blockNum;
 
    return rfalNfcvPollerTransceiveReq( RFAL_NFCV_CMD_READ_SINGLE_BLOCK, flags, RFAL_NFCV_PARAM_SKIP, uid, &bn, sizeof(uint8_t), rxBuf, rxBufLen, rcvLen );
}
 
/*******************************************************************************/
ReturnCode rfalNfcvPollerReadSingleBlockCustom( uint8_t flags, const uint8_t* uid, uint8_t blockNum, uint8_t* rxBuf, uint16_t rxBufLen, uint16_t *rcvLen )
{
	uint8_t bn[2];
 
	bn[0] = blockNum;
	bn[1] = 0; //append {blockNum, 0} after uid to read 1 record (0+1) starting from blockNum
	//return rfalNfcvPollerTransceiveReq( RFAL_NFCV_CMD_READ_SINGLE_BLOCK, flags, RFAL_NFCV_PARAM_SKIP, uid, &bn, sizeof(uint8_t), rxBuf, rxBufLen, rcvLen );
	return rfalNfcvPollerTransceiveReq( 0xC0,			/*custom command 0xC0*/
										/*flags*/0x22, 	/*flag addressed mode + bitrate*/
										/*RFAL_NFCV_PARAM_SKIP*/0x4, 		/*manufacturer code - Prepend parameter on certain proprietary requests. For default commands skip: RFAL_NFCV_PARAM_SKIP*/
										uid, 								/*uid*/
										&bn, 								/*buffer of bytes to append after uid - command parameters append after UID*/
										/*sizeof(uint8_t)*/2, 				/*number of bytes to append after uid - command parameters Len*/
										rxBuf, 								/*same as rfalNfcvPollerReadSingleBlock*/
										rxBufLen, 							/*same as rfalNfcvPollerReadSingleBlock*/
										rcvLen );							/*same as rfalNfcvPollerReadSingleBlock*/
}

Both use the rfalNfcvPollerTransceiveReq() API, custom wrapper use the custom command code (0xC0), the MFG code (0x4 instead of RFAL_NFCV_PARAM_SKIP), the command parameter buffer, in my cas {0xA0, 0} to read 1 regiter (0+1) from 0xA0.

It seems to me that i've used the rfalNfcvPollerTransceiveReq interface as is described by the header file:

*****************************************************************************
 * \brief  NFC-V Transceive Request
 *  
 * Performs a generic transceive with an ISO15693 tag
 *
 * \param[in]  cmd            : NFC-V command
 * \param[in]  flags          : Flags to be used: Sub-carrier; Data_rate; Option
 *                              for NFC-Forum use: RFAL_NFCV_REQ_FLAG_DEFAULT
 * \param[in]  param          : Prepend parameter on certain proprietary requests
 *                              For default commands skip: RFAL_NFCV_PARAM_SKIP
 * \param[in]  uid            : UID of the device to be put to be read
 *                               if UID is provided Addressed mode will be used
 * \param[in]  data           : command parameters append after UID
 * \param[in]  dataLen        : command parameters Len
 * \param[out] rxBuf          : buffer to store response (also with RES_FLAGS)
 * \param[in]  rxBufLen       : length of rxBuf
 * \param[out] rcvLen         : number of bytes received
 *  
 * \return ERR_WRONG_STATE    : RFAL not initialized or incorrect mode
 * \return ERR_PARAM          : Invalid parameters
 * \return ERR_IO             : Generic internal error 
 * \return ERR_CRC            : CRC error detected
 * \return ERR_FRAMING        : Framing error detected
 * \return ERR_PROTO          : Protocol error detected
 * \return ERR_TIMEOUT        : Timeout error
 * \return ERR_NONE           : No error
 *****************************************************************************

Am I using properly rfalNfcvPollerTransceiveReq?

I did also a data dumping from gRFAL.TxRx.ctx.txBuf and gRFAL.nfcvData.codingBuffer (inside rfalTransceiveTx) on both 3911B and 3916B to compare if transmitted data are different. In both cases txBuff and codingBuffer are identical.

To me is strange that without changing any transceiver configuration, write and read works, custom write works but custom read doesn't. Consider that they are called in sequence inside exampleRfalPollerDataExchange().

Best regards, Antonio

[Brian TIDAL · Accepted solution]

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