cancel
Showing results for 
Search instead for 
Did you mean: 

Mitigating hard framing and CRC errors in Reader/Writer mode

LltWc
Associate III

I've been seeing some unexpected failure modes while reading T2Ts with an ST25R3916. Every ~300ms, the device sends a wake request, and if a tag is detected, goes ahead with the reading process. If a tag is detected and an error occurs anywhere in the read process, from anticollision to reading block by block, the read process will reset up to 5 times. Every time a tag is detected, the retries reset. For example, if a tag is detected, anticollision complete, and read up to block 20 before a CRC error is triggered, it will then send out five more tag detects. If there's a response to the 4th tag detect, it will begin the process again.

Normally, the device rapidly reads a tag quickly and smoothly. But I've been seeing the device occasionally hang while sitting on top of a tag (well within range) for 10 seconds or more without reading. When I look at the logs, it's a series of hard framing errors (typically), and sometimes CRC or parity errors, and the 5 retries almost never trigger a tag detection.

This leads me to two questions:

1) Is there a way to determine what's causing these errors and mitigate it? The spec does not go into any details about the interrupt error flags.

2) Is there a reason that the subsequent wake request retries rarely get a response? It's about 30ms in between retries. I've tried it with and without toggling Tx/Rx on and off between retries, and even with a Field On command. While debugging I've put a 10ms delay after the re-enablement, so it's definitely not violating the guard time rule.

2 REPLIES 2
Ulysses HERNIOSUS
ST Employee

Hi,

are you here using RFAL and its default analog configs? Or you are on something self-cooked?

I don't fully understand your sequence. What do you mean by "wake"? WUPA command? In the end it will be also helpful to get a logic analyzer trace of your sequences.

Well CRC error you get when the check of the CRC fails. Hard framing error are happening if the a bit cannot correctly decoded (no subcarrier or subcarrier for the complete bit duration, erros in SOF or EOF).

BR, Ulysses

This is custom firmware, the RFAL isn't compliant with the requirements for our RTOS-based system. 

Yes, wake is a WUPA command. Every time the device goes to Reader Mode, it sends a WUPA to try to detect a tag.

While continuing to look for a fix, I spoke to our hardware team who told me that between the devices exhibiting this behavior, and the devices that don't, the ferrite shield was reduced from fully covering the area between the antenna and the rest of the device to covering only the flex antenna. That looks like it sufficiently explains what I've been seeing.

I also set corr_s6 in the correlator configuration register 1 to help ensure that tags are only read when they can actually be communicated with. On my tests so far today, that seems to help as well, but I do still (occasionally) see the device sit on top of a tag for 5-10s and show framing errors.

Does ST have any information on working with ferrite shield/NFC detuning? I found some resources from NXP in their PN7160 guide, but there isn't anything similar in the ST25R39 application note.