CLRC - Inconsistent results

[solsbarry]

I am trying to communicate with a ISO 14443 Type A tag at 106 kbs.

I am using a CLRC663 Reader chip from NXP. We will call this reader, R1.

I have a custom driver I wrote to run my reader, and communicate with it over the uart using a silabs bridge.

My tag is a custom battery powered device running a NRF52840 SOC.

I have an old reader that uses a PN532 and can communicate with my type A tags fine. We will call this reader R2.

Using R1, I can talk to Type B tags fine, no issues.

But when I try to talk to type A tags I have an issue.
The issue is that that after I power cycle my tag, I can only activate it one time. After its active I can send as many C-APDU as I want,
But as soon as I deselect and power off the field, I am unable to active the tag again.
THe same sequence from the reader does not get valid responses from the tag. It fails to respond to the REQA or WUPA sometimes, or if it does, it fails early in the anti-collision loop. Just nothing in the reader fifo as a response.

If I power cycle the tag, I can activate it again.

But at any time my old reader (R2) is able to communicate. For example I can activate and send commands with R1, then activate and send more commands with R2, over and over and R2 works any time. But if I try to use R1 it fails. And I can use R2 after an R1 failure no problem. But I can't get R1 to work again until I power cycle the tag. Using R2 first will also cause the issue with R1 subsequently. So its not like it is something that R1 sends specifically that causes the issue.

So it must be that there is something persistent on the tag that after interaction with R1 or R2 once it can't communicate with R1 again. And that persistent thing is only fixed by a power cycle of the tag. But whatever the persistent thing is has no effect on R2.

I have a SDR that I am using to look at the NFC traffic. It is good enough to see the Reader commands, but not really the tag responses. I can see some jitter in the signal from the responses, but my resolution is not good enough to really capture it.
In the signal I can see, I see that even with the failures, the tag is responding to R1 in some way, even though R1 is seeing incomplete or no responses when I have the failures.

I also see that at layer 3 my Commands from R1 and R2 are the same data, and basically the same physical signals (although there are differences). So its not what I what is being sent. It must be how it is being sent. Or how the responses are being received. And I can't see why removing the field and bringing it back has this persistent effect on the tag. Or why it only affects R1. I have tried adjusting the registry settings in R1 any number of ways with little effect. My ability to modify the tag emulation on the nrf54840 is very limited, so I am not sure there is much I can do there. And since R2 always works it seems like I should be able to adjust something on R1 and make it work, but I am basically out of ideas.

Any help would be appreciated.

[Fabian_R]

Hello sir,

Thank you very much for your interest in CLRC663. I agree that the issue might be in the CLRC663, and I would like to start working on a common ground. Could you please clarify if you are using the CLRC663 evaluation board for this testing? Additionally, it would be great to test the IC with one of our software. I understand that you want to use your driver but for this testing stage, it makes some sense to use NFC Cockpit to see exactly what are the commands being sent using Layer 14443 Data Exchanged with PICC function. This will give us some more information on the data exchange.

[solsbarry]

More notes:

1. When first powering the tag, using R1, if I turn the field on and do nothing. then turn it off. Then try to activate it doesn't work (the response is to the REQA is bad).
2. When first powering the tag, using R1, if I turn on the RF I can send any commands I want, including HLTA and the nreactivate as long as I don't power off the RF. But as soon as I turn off the carrier wave once(for any amount of time), nothing works (bad responses to REQA) the next time the field turns on.
3. Reader 2 always works. It doesn't matter if the RF powers off. It doesn't matter if I run R1 first, then R2. It always works. And all it does is send REQA first, just like I do with R2. Well actually R2 tries 3 REQB commands and then a REQA command which works. But I tried that too with R1, and it didn't help.