Not able to read the UID from tags

[KElli.1]

I'm using an ST MCU (STM32F765VGT6) on a custom board, wired to an X-NUCLEO-NFC06A1 communicating via I2C. I've integrated the RFAL library into an existing codebase. I've taken elements of the Disco demo code into our codebase, to exercise the RFAL. (It is based on the PollingTagDetect example, demo_polling.c, from STM32CubeExpansion_NFC6_V1.1.0)

I am able to detect a tag, but the UID is returning as blank. I'm not seeing any I2C traffic on the Saleae analyzer that looks like the ID, so I don't think it is being retrieved from the reader. The code isn't breaking anywhere that seems to write to nfcId1, but it's a little hard to track down which variable it's actually stored in. Can you point me to where in the RFAL library you'd expect the nfcId1 variable to be stored for a NFCA type 2 tag? 

For I2C are there any gotchas similar to the SPI gotachas (where you need to have a separate GPIO controlling CS)? 

Any other suggestions for tracking this down? 

Thanks,

Katie

[Ulysses HERNIOSUS]

Hi Katie,

do you want to say that you enter:

 if( rfalNfcIsDevActivated( rfalNfcGetState() ) )
 {
 rfalNfcGetActiveDevice( &nfcDevice );
 switch( nfcDevice->type )
 
...
 
 default:
 platformLog("ISO14443A/NFC-A card found. UID: %s\r\n", hex2Str( nfcDevice->nfcid, nfcDevice->nfcidLen ) );

and in the switch it prints but nfcId is empty? This would sound more like an issue in your print implementation.

Inside our RFAL the nfcId1 should be copied inside rfalNfcPollActivation() from nfcId1 into nfcId.

Best Regards, Ulysses

[KElli.1]

Yes, exactly. But it is not print: when I break in code, nfcidLen = 0, and nfcid is all zeros. I assume they have not been modified since they were initialized, and that the problem is that I'm not getting to wherever they are set. I am not exactly sure where that is. I am also not seeing any I2C traffic with the UID, so it doesn't look like we retrieved it from the reader.

Thanks,

Katie

[KElli.1]

To follow up, in rfalNfcPollActivation we copy from nfcid1, but nfcid1 is also 0. So where should nfcid1 be set? Or rather, where in the library is the actual request to the reader to return the ID (a FIFO read)?

Thanks,

Katie

[Ulysses HERNIOSUS]

Hi Katie,

in the end this is done through calls to rfalISO14443AStartTransceiveAnticollisionFrame().

Symptoms like you are explaining here may be caused by insufficient protection of the I2C calls from both main and interrupt level.

Please check those and if you find nothing then it would be beneficial if you can share logic analyzer traces (I2C + INT pin) to see what is going on.

Best Regards, Ulysses

[KElli.1]

I've attached a capture of a Saleae trace including I2C + INT. I believe I have sufficient protection, but I will double check in the I2C driver as well. Thank you very much for your time.

-Katie

[KElli.1]

Hi Ulysses,

Thank you for the I2C tip. I believe I have resolved that part of the issue and am properly accessing the Register B space. However, I still don't see a read of the ID. I've attached another Saleae trace.

Should I be getting to the RFAL_NFCA_CR_SEL case in rfalNfcaPollerGetSingleCollisionResolutionStatus? That seems like a place where the ID is written, but we are not getting there.

Thanks,

Katie

[Ulysses HERNIOSUS]

Hi,

I saw some glitches on INT pin and enabled the glitch filter (1us). The last interrupts happening indicate I_rxs,I_rxe @7.138sec from the chip, so part of the UID is received, then some other I2C slave is addressed (addr 0x90) followed by clean-up of the transceive but no reading of FIFO data).

I suspect long delays in your code and software going into error handling despite interrupts happending correctly (could also be related to MCU timers).

Best Regards, Ulysses

[KElli.1]

Hi Ulysses,

I removed some printing which could have caused delays along with access to the other I2C device. (and also fixed the ground problem causing those glitches)

At 3:77ms, I see it read the FIFO status register, which looks like it says only 2 bytes are available. I was expecting more (aren't we getting the UID?). Then it reads 2 bytes from the FIFO, but those 2 bytes don't correspond to what I'd expect. The tag ID is: 04:38:81:EA:F4:73:81

Are there particular error handling functions I could check for in the code?

See attached Saleae trace.

Thanks,

Katie

[Ulysses HERNIOSUS]

Hi,

the 2 bytes is the ATQA (44 00 - answer to WUPA) which does not carry UID bytes.

I find in the trace a place where part of the UID is read (the first cascade level (response to 93-20):

The reception of this UID bytes is happening at an unexpected place - software seems to have already advanced to somewhere else as it was doing multiple register accesses since the I_rxs. Also after that it does not move on to second cascade level (eg. sending 95 -20)

How does your I2C driver work? Any chance of out of order executions or dropped I2C requests?

Also the trace is hard to follow due to crosstalk from SCL onto SDA (Here it should read as A0 - 5A - A1- 10 - 00 00 00 (I_rxe), which appears after enabling the glitch filter on SCL (1sampe).

And last tip: Saleae V2 software supports better searching in frames, etc instead of only looking at single bytes.

Best Regards, Ulysses

[Ulysses HERNIOSUS]

Addendum,

the register settings in between I_rxe and FIFO handling could also be caused by additional RFAL calls in between - rfalGetTransceiveStatus() not yet signaling done, but calling RFAL APIs before again calling rfalWorker(). Does your software do any such? Maybe you put some logs there to follow the flow of RFAL calls from your application layer.

Best Regards, Ulysses