2021-11-25 11:30 PM
Hello, I'm playing nfc on the ST25R3916 board.
Currently, Tag is ISO/IEC 15693 and Firmware uses STSW-ST25R011.
Write works well, but sometimes "time out errors" occur in the Read, GetSystem Information command, which requires response data. Is there a reason and solution?
Below is the code for the current test.
static Menu_Callback_Status_t tabTagWriteNdef(void)
{
ReturnCode rc;
rfalNfcvInventoryRes InvRes = gDevList[0].dev.nfcv.InvRes;
uint16_t rcvLen;
uint8_t buffTmp[0x20]; // GetsystemInfo response data
uint8_t rxBuf[ 1 + 4 + RFAL_CRC_LEN ]; // Read response data
rc = rfalNfcvPollerReadSingleBlock(RFAL_NFCV_REQ_FLAG_DEFAULT, InvRes.UID, 0, rxBuf, sizeof(rxBuf), &rcvLen);
rc = rfalNfcvPollerGetSystemInformation(RFAL_NFCV_REQ_FLAG_DEFAULT, InvRes.UID, (uint8_t *)buffTmp, sizeof(buffTmp), &rcvLen );
return MEND_CALLBACK_LAST;
}
I'd appreciate it if you could answer me.
Solved! Go to Solution.
2021-11-29 06:28 AM
Hi,
the rc=4 means ERR_TIMEOUT, i.e. ST25R3916 did not receive/recognize a response.
Given that you experience this issue only when reducing the EM4425 block size from 8->4 I strongly suspect an issue in the tag implementation / maybe your expectations on the tag. I suggest to check with EM/their DS.
Best Regards, Ulysses
2021-11-25 11:48 PM
Hi LJooS.1,
hard to say who is to be blamed for such. How often does it fail?
Also please beware that GetSystemInfo is an optional command, there are ttags which will never respond to it. But I assume you have one tag which is sometimes answering and sometimes not?
Which tag is that?
Also if you would have a logic analyzer it would be most beneficial to see a trace of SPI+IRQ of it.
BR, Ulrich
2021-11-25 11:57 PM
HI Ulrich .
I'm using the EM4425 tag.
In the case of Read command, either response data = 0x00000002 or data of the corresponding block appears as response data. (The same goes for GetSystemInfection command)
Is there a logic analyzer that you can recommend?
2021-11-26 02:10 AM
Hi,
reading that also the read command returns invalid data, I start to suspect a buffer / stack / overwrite issue on MCU. But I cannot spot anything suspicious on your code.
When doing traces I advice to enable also commented code parts (#if 0 -> #if 1) inside RFAL around the calls of rfalIso15693VCDCode() and rfalIso15693VICCDecode() to have easily interpretable information on the SPI trace.
In our experience most logic analyzer work (and also can decode SPI).
BR, Ulrich
2021-11-26 03:58 AM
Hi,
when rfalNfcvPollerReadSingleBlock returns an error, the rxBuf has no valid content. Can you check the rfalNfcvPollerReadSingleBlock return code and share with us? In case an error code is returned by the tag, this error code is parsed in rfalNfcvParseError. You can set a breakpoint here and see the error code returned by the tag if any.
EM4425 is a dual interface tag combining HF and UFH interfaces. Can you check with a pure HF product such as ST25TV02K.
Do you use the ST253916-DISCO or your own custom board on top of ST25R3916 IC?
Rgds
BT
2021-11-29 01:14 AM
Thank you. I'll give it a try!
2021-11-29 01:43 AM
Hi Brian TIDAL.
1. Can you check the rfalNfcvPollerReadSingleBlock return code and share with us?
a : The current test code is as follows.
static Menu_Callback_Status_t tabTagWriteNdef(void)
{
ReturnCode rc; // return value (read command)
uint16_t rcvLen;
rfalNfcvInventoryRes InvRes = gDevList[0].dev.nfcv.InvRes;
uint8_t rxBuf[ 1 + 4 + RFAL_CRC_LEN ] ={0x00,}; // RFAL_CRC_LEN = 2
uint8_t * rxd ;
rc = rfalNfcvPollerReadSingleBlock(RFAL_NFCV_REQ_FLAG_DEFAULT, InvRes.UID, 0, rxBuf, sizeof(rxBuf), &rcvLen); // read 0block (CC block)
rxd = hex2Str( &rxBuf[1], 4);
}
If successful, rc = 0, and if failure, rc = 4. In addition, in case of failure, the response value does not come to rxBuf.
Also, is the error code of rfalNfcvParseError you mentioned as below? (rfal_nfcv.h)
/*! NFC-V Error code ISO15693 2000 7.4.2 */
enum{
RFAL_NFCV_ERROR_CMD_NOT_SUPPORTED = 0x01U, /*!< The command is not supported, code is not recognised */
RFAL_NFCV_ERROR_CMD_NOT_RECOGNIZED = 0x02U, /*!< The command is not recognised, format error occurred */
RFAL_NFCV_ERROR_OPTION_NOT_SUPPORTED = 0x03U, /*!< The option is not supported */
RFAL_NFCV_ERROR_UNKNOWN = 0x0FU, /*!< Unknown error */
RFAL_NFCV_ERROR_BLOCK_NOT_AVALIABLE = 0x10U, /*!< The specified block is not available */
RFAL_NFCV_ERROR_BLOCK_ALREDY_LOCKED = 0x11U, /*!< The specified block is already locked */
RFAL_NFCV_ERROR_BLOCK_LOCKED = 0x12U, /*!< The specified block is locked */
RFAL_NFCV_ERROR_WRITE_FAILED = 0x13U, /*!< The specified block was not successfully programmed */
RFAL_NFCV_ERROR_BLOCK_FAILED = 0x14U /*!< The specified block was not successfully locked */
};
2. EM4425 is a dual interface tag that combines HF and UFH interfaces. Can you check with pure HF products such as ST25TV02K.?
a: There is no product above, and it was test with NXP's ICODE SLIX tag. It works normally. (R/W command)
EM4425 is initially 8 bytes per block.
At the initial time, R/W becomes successful.
However, after changing to 4 bytes per block, there are cases where response data may not be received when read.
3.Do you use the ST253916-DISCO or your own custom board on top of ST25R3916 IC?
a: ST25R3916-DISCO board is being used.
Rgds
JS
2021-11-29 06:28 AM
Hi,
the rc=4 means ERR_TIMEOUT, i.e. ST25R3916 did not receive/recognize a response.
Given that you experience this issue only when reducing the EM4425 block size from 8->4 I strongly suspect an issue in the tag implementation / maybe your expectations on the tag. I suggest to check with EM/their DS.
Best Regards, Ulysses