- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Tool/software:
I am experiencing an issue when performing an inventory command on select ISO 15693 RFID tags. The last received byte of the UID (0xE0) appears to be getting overwritten by the first byte of the CRC (for example, 5BE20739080104B0 is returned instead of the expected 5BE20739080104E0 - I understand that this is technically the first byte of the UID). If returning the CRC as well, then the 0xE0 byte is correct, but last received byte of the CRC is incorrect (for example, 5BE20739080104E0B0F7 instead of the expected 5BE20739080104E0B049). This is an intermittent issue that is only seen on select RFID tags paired with select TRF ICs (tags failing with one board will pass with another).
I manually decoded the transmission of the inventory command to the tag to confirm that it is being sent correctly. Similarly, I decoded the received digitized subcarrier signal from the tag on the MOD pin, which is confirmed to contain the correct response. However, the incorrect byte can be seen when probing the SPI bus between the TRF7970A and the MSP430. Since the TRF does not raise any concerns when performing the CRC calculation on the received UID, this leads me to believe that the issue occurs when either writing-to or reading-from the FIFO buffer.
Two methods that appear to resolve this issue are detuning the antenna/signal (by introducing metal in the field or by changing the 0x0A register) or by changing the modulation depth in the 0x09 register (100% OOK causes the issue and any ASK modulation between 7-30% appears to resolve the issue). This works for both signal and 16-slot inventories.
Can this behavior be explained, as well as why changing the modulation depth, for example, resolves this issue? Or possibly something else is being configured incorrectly? Any insight is greatly appreciated.
Thank you.
Hi,
Is the problem observed in the very first read cycle or you might have repeatedly read the UID and it was one of the later read cycles that you saw the corruption? In another word, how long does it take you to see the E0 overwritten by the CRC? When you start a read cycle, did you do a SOFT INIT?
Can you also check if if register at 0x18 is initialized to 0?
Please also tell me if you are referencing the TI example firmware (SLOC297)? If you run the SLOC297 firmware, do you see the same issue?
