cancel
Showing results for 
Search instead for 
Did you mean: 

NXP tag read problem and it's not detected

kolwas
Associate II

I am using ST25NFC_Embedded_Lib_ST25R3916_1.4.0 on

STM32L5 discovery board with X-NUCLEO-NFC06A1

And I have no problem to detect and read ST Tag (always correct), but if I use NXP tag I have super strange behavior.

On bare-metal application, it works on ST+NXP tag.

But on our application that use DMA SPI, and it's 4x slower on CPU I can read st tag but NXP no. He didn't say that he detected anything. From code debug I founded that resolving of NFC conflict always return BUSY and it all. I removed DMA on SPI and still (as the DMA for that short operation give some overhead), but there is a problem. Code is mostly the same, lib is just copied.

For me, it looks that this library have a problem on working on more restricted environment. Could you say how to make it working?

PS> Before removing DMA I had a problem that protected areas in that lib prevented for getting to interrupt.

11 REPLIES 11
Brian TIDAL
ST Employee

Hi,

can you precisely describe your hardware setup? In your initial post, you referred to "STM32L5 discovery board": is this a STM32L562E-DK board? Is the X-NUCLEO-NFC06A1 directly connected to the Arduino (R) Uno connectors? If an STM32L562E-DK is being used with the Arduino connectors, a part of the X-NUCLEO-NFC06A1 antenna seems to cover the mother board PCB, thus this may be a cause for electrical disturbances. Can you try to connect the X-NUCLEO-NFC06A with relatively short wires to avoid overlap between the mother board BCP and the antenna?

Can you try to provide new Salae traces (make sure the logic analyzer cables are 'far' from the antenna and not subject to disturbances)?

Rgds

BT

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Hi,

in above trace it was getting to RFAL_NFCA_CR_SEL_TX with the NFC-A tag. I understand that it will not be easy for you to debug our driver logic. But what you could still do is debugging the SPI driver calls (using logging) vs the bytes observed using logic analyzer.

I assume you will need to first improve the signal quality as observed on the logic analyzer and then look at the data bytes. Ideally you could straight look at the unique pattern as above which was present in both traces.

If this is not possible then I think it should be possible to use a diff tool to see differences in logic analyzer output (exported/sent to terminal) vs logs which you could add to your SPI driver.

Good hunting!

Ulysses