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,

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

[KElli.1]

I copied the code from demo_polling.c from NFC6_V1.1.0. I've attached my thread. I have copied demoCycle() as nfc_reader_process_tags(), which is called from an infinite loop, with a configurable delay between calls. I can't go below a 40ms delay without causing problems in the system with watchdog, etc.

See attached (and lightly sanitized) nfc_reader_task.c and the platform.h that I am using. 

You asked about the I2C driver. We have write functions that utilize the ST LL_* drivers to do the following: wait for the bus to be ready, generate the start condition and send the device address, wait for TXIS or NACK, write reg address, send the data, and generate the stop. Similar for read. Our I2C driver doens't mesh well with the ST rfal code which expected the start/stop/address stuff to be all in separate functions. But it appears to me that the I2C accesses are working ok now. I haven't seen any partial writes or reads, and I'm not getting I2C errors. 

I'm using the old logic because I have a very old Saleae that isn't compatible with the newer software. I'll try to get a trace with a newer Saleae. 

[Ulysses HERNIOSUS · Accepted solution]

Hi,

I don't spot anything suspicious in your code.

Please analyze/debug the unexpected sequence as per this image:

The question is how does it come to this unexpected call to rfalNfcaPollerInitialize().

I am suspecting that you are calling rfalNfcWorker() not often enough and some timer signals a fundamental problem.

Best Regards, Ulysses