NXP tag read problem and it's not detected

kolwas · ‎2022-11-14

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.

Ulysses HERNIOSUS · ‎2022-11-16

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

View solution in original post

Brian TIDAL · ‎2022-11-14

Hi,

can you connect a logic analyzer on SPI (CLK/MOSI/MISO/CS) and IRQ_3916 and provide the trace when you try to poll the tag.

"On bare-metal application, it works on ST+NXP tag." Is your final application based on an RTOS?

"I had a problem that protected areas in that lib prevented for getting to interrupt." The ST25NFC Embedded Lib is pure bare metal source code, what do you mean by protected area in that lib?

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.

kolwas · ‎2022-11-14

We don't have OS. This is BSP that give abstraction over HAL just for easy option to change MCU, at the end simple, gives also a basic tools for making sleeps etc. it gives additional overhead :( we also decreased MCU speed to make it more power efficient to 16MHz . Protection area is "platformProtectST25RComm" from library. It gives an option to cover real interrupt if communication is too long.

The number of problems is getting bigger if you slow down communication and CPU speed, as this "protection" is then preventing normal IRQ from rising.

I added saleae analyzer output for working/not working device

kolwas · ‎2022-11-14

In addition, please see that if chip select is on, then you are in the described above protected area

kolwas · ‎2022-11-14

This is better without initiation

kolwas · ‎2022-11-14

The code in rfal_nfc.c, err= ERR_TIMEOUT

        err = rfalNfcaPollerGetFullCollisionResolutionStatus();
        if( err != ERR_BUSY )
        {
            gNfcDev.isTechInit = false;
            gNfcDev.techs2do  &= ~RFAL_NFC_POLL_TECH_A;
            ...

Ulysses HERNIOSUS · ‎2022-11-14

Hi,

I reviewed the traces (also downloaded and enabled the SPI transaction framer).

Reviewing the traces I see not soo good signal quality on the signals:

Missing clock pulses
Weird signal on IRQ line: going low prematurely and ringing
One time the IRQ line (during init) was staying high 100ms, not handled by ISR
To the question of ST tags working vs NXP tags: The used ST tags were NFC-V whereas the non-working were NFC-A
There seems to be an issue in your porting as the command bytes in NFC-A ends up wrong on SPI bus:It should be RFAL_NFCA_CMD_SEL_CL1 (0x93) but ends up as 0x00: 0x800070 instead of 0x809370. This is why the tag does not respond to the select on first cascade level. Please debug the code to see why the 0x93 does not get out.

I also recommend to look into signal integrity - shorten your flying wires. Twist the wires and move away perpendicular to the antenna.

Best Regards, Ulysses

kolwas · ‎2022-11-16

Hello,

this is standard nucleo board without any changes and workaround in both our so no HW changes can be here made - pin to pin how ST have produced that only logic analyzer have additional cables.

On the example that I made on pure bare-metal NXP, tags are working just by default, so I assume that it should work the same. The strange things that ST tags always works. It appears ONLY on NXP one.

I will try to debug what happened there with that command, but from what I see it is hard to add something more. As for now, I just connected HAL functions. I checked if the code is the same, and it looks the same. Only difference for now is IRQ handling and speed of MCU and SPI

With regards JK

kolwas · ‎2022-11-16

Also the problem is that I didn't modify ST library as well I am not author so from my perspective it's really hard to debug it. What should I search there? As HAL sent command, I assume are working same - quite taught to debug not knowing deeply NFC

kolwas · ‎2022-11-16

I tried and how I see it even not reach "case RFAL_NFCA_CR_SDD_TX:" so he never sends that command