This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TRF7964A: Collision error received during a page causes unexpected operation

Part Number: TRF7964A
Other Parts Discussed in Thread: TPS61042

Sir or Madam,

My RFID project is now working fine except that occasionally, during a FAST_READ operation from an NTAG21x tag, a collision error is reported in bit 2 of register 0x0C.  When any error is reported during the EORX interrupt, the firmware restarts the operation by resending the read command sequence which is the following.

0x01, 0x08  Enable CRC checking

0x10, 0x02  Enable normal receive and normal framing

0x8F  Reset the FIFO

0x91  Transmit with CRC

0x3D, 0x00, 0x30  Transmit the following three bytes

0x3A, 0xNN, 0xNN FAST_READ command for page NN.

For received CRC errors this restarts the operation and all goes well.  For collision errors, the restarted operation times out after 30 ms.  The firmware automatically retries failed reads up to 5 times and this particular error fails the 4 following retries with the EORX timeout.  The carrier remains on during retries.  The low level driver only reads one page at a time due to timing restrictions in the system however it is able to read contiguous blocks of pages in this manner.

I have scanned the datasheet and could not find any mention of special handling of collision errors when the tags is selected and active.  The tag is used in a slightly noisy environment and occasional CRC errors are detected and properly corrected via retires.  Collision errors during reading always fail.  What am I doing wrong?

Best regards,

Al Otis, Jr

  • Hello Alton,

    After states where collision errors are expected to occur such as tag detection/activation, any collision errors the TRF7964A receives should be treated no differently than CRC or Parity Errors. It is not unusual to see Collision Errors rather than CRC Errors when the RF signal has been interfered with/corrupted by noise/etc.

    Sometimes these errors can only be resolved by soft resetting the device which we recommend by doing with a 0x03 direct command (SPI 0x83), followed by a 0x00 direct command (SPI 0x80), followed by a 1ms delay.
  • Ralph,

    I tried your recommendation but it did not appear to have any effect on the problem.  The software reset command resets the chip status control register (0x00) to 0x01 turning off the carrier which I assume after 1 ms causes the tag to go to the POR state thus requiring reselection to the ACTIVE state.  Is this a correct statement?  If not how long will the tag remain in the active state with the carrier removed?

    To solve the problem in my application I now precede all read/write retries with a deselect followed by a new select.  The deselect does the following.

    1)  Set register 0x00 to 0x01 to turn off the carrier.

    2)  Delay for 20 ms to ensure the tag is in the POR state.

    3)  Set EN low.

    The select does the following.

    a)  Set EN low for 1 ms then high (for the case that the tag was not previously deselected).

    b)  Issue a software reset then wait for the osc_ok bit to be set (5 ms time limit).

    c)  Set register 0x00 to 0x21 to enable the carrier.

    d)  Wait for 7 ms for the tag to complete POR and enter the IDLE state.

    e)  Proceed with anticollision until the ACTIVE state is reached.

    Now on several runs of 100 full reads of an NTAG216 tag there have been less than 5 CRC errors per run and no more than one retry per error.

    FYI:  The system closely couples the tag and the reader antenna.  The spacing is less than 5 mm and the closest a second tag could get to the antenna is greater than 30 mm.  During anitcollision processing any collision error is treated as noise and the process is retried (deselect then select).  The noise source is a TI TPS61042 LED switching back light driver which is about 10 mm away from the tag and generates 19 V 500 KHz pulses at the inductor output.  The driver circuit is now covered with a grounded copper shield which is very effective.

    Thank you for directing me to the TI C code for the TRF7964A.  It was helpful in completing my ARM assembler coded firmware.

    Comments please.

    Best regards,

    Al

  • Hello Alton,

    Alton Otis Jr said:
    The software reset command resets the chip status control register (0x00) to 0x01 turning off the carrier which I assume after 1 ms causes the tag to go to the POR state thus requiring reselection to the ACTIVE state.  Is this a correct statement?

    It is likely less than 1ms, as the tag is passively powered by the RF field and as soon as it removed, then the tag will reset state. I recommended that as a method to recover the TRF7964A internal state machines which can end up in recurring errors unless it is reset that way (rare, but it has happened in noisy environments). The method definitely requires full tag reactivation.

    I don't feel 30mm is enough distance to be sure to avoid collision, that's well within standard read range for NFC technologies. You may observe collisions or other errors if the tags get that close together.

    I don't think the switcher noise would affect the RF communication at that low of frequency typically but if the inductor was not shielded then I could see that being more of an issue.

  • Ralph,

    Thank you for your usual prompt reply.  Just a few more comments and I will close this ticket.

    The RFID antenna is a 1 uH unshielded barrel inductor with the magnetic axis coaxial with the tag antenna magnetic axis.  The tag is a custom design with a 12 x 12 mm square spiral antenna.  The top of the inductor is 3 mm below the plane of the tag.  At this position the RSSI level is 7.  Moving the tag to 5 mm separation drops the level to 3 with poor communication.  At 10 mm there is no communication.  Because of the physical positioning of the tag and antenna with in the product case the closest an external tag could be placed that is coaxial with the antenna is 50 mm with three intervening ground planes.  Outside of the case with no intervening ground planes placing a second custom tag 3 mm above the normal tag position or a 25 mm commercial tag 30 mm above the normal tag position yields no collision errors.  I believe we are safe from secondary tag interference.

    The back light switcher uses a shielded SMT inductor and I agree with you that it seems unlikely this would be a cause of interference.  However interference with the RFID subsystem dramatically dropped from considerable to almost nil once the copper shield was added.  The degree of interference was a function of the PWM level with 0 and 100 yielding no interference and 50% (the normal level) yielding maximum interference.  So the interfering signal is a byproduct of the mixing of the switching frequency and the PWM frequency.

    Many thanks for all of your help and I hope I do not have to bother you again for this project.

    Best regards,

    Al