How to integrate NFC Reader ST25R3911B into my own program.

[JNieu.1]

Hello!

I have been working with the NFC05A1 NFC Reader in combination with a G070RB, but am momentarily stuck on how to use it in my own program.

I have followed all the steps given in an other post with a person having close to the same issue: https://community.st.com/s/global-search/25R3911B?t=1595829552630

But I keep getting errors left and right on includes and functions, which makes me come to a question whether all of this is needed for just a 'simple' program.

My main question here is whether there is an easy way to implement a program to read the UID from an NFC Tag. It's all my program has to do, the example given in the X-CUBE-NFC5 seems a little too much for what I want it to do.

Kind regards,

Joey

[Ulysses HERNIOSUS]

Hi Joey,

Well, on software layer we have invested to make ST25R95 , ST25R3911B and ST25R3916 identical. However as the 95 is a completely different IP its interface on the lower level and the schematic are quite different.

IRQ_IN is an input from 95 perspective so needs to be configured as output on the MCU.

IRQ_OUT is an output from 95 perspective so needs to be configured as input on the MCU.

For your undefined references: Please check that you have rfal_nfc.c included.

Regards, Ulysses

[JNieu.1]

Hi Ulysses,

For just reading the UID from a card, does it make a big difference whether I use the ST25R95 (Or currently on my NFC03A1 the CH95HFV5), or the ST25R3911B?

I have made the changes to the IRQ Inputs and outputs.

For the undefined references, I have both "/Middlewares/rfal/Inc" and "/Middlewares/rfal/Src" included in my projects include paths (I think only /Inc has to be included there though) but it keeps giving me the errors.

If I try to include the rfal_nfc.c file itself, it will give me an error that I have multiple definitions of the functions in the file.

Kind regards,

Joey

[Ulysses HERNIOSUS]

Hi,

For reading a UID it does not make any difference which board/chip you use. However on porting the 391x and 95 are a bit different (SPI mode, pins, etc.). If you go for designing an own board you will also encounter substantial differences.

I am no expert on STM32CubeIDE IDE. What I see is rfal_nfc.c among other files does have a different icon. When you select "Build selected file" no actual build is started. Also rfal_nfc.o does not appear in Debug/objects.lst.

So somehow the files in Middleware/rfal were not correctly added.

Regards, Ulysses

[JNieu.1]

Hi Ulysses,

What would your advise be on which chip to use for certain purposes?

I have yet to figure out why it doesn't build the /Middlewares/rfal, but so far I have worked around it by putting all the files in my /Core/Inc and /Core/Src.

I have checked the connection and my pin layout is correctly set up in the .ioc file. But I am getting a HAL_TIMEOUT error whenever my demo tries to initialise.

The error happens first in the st25r95SPIPollRead function in the st25r95_com_spi.c file.

First of all, is there any difference in this function being used for the ST25R95, because I am not using that one, and I am using the CR95HFV5.

Second, if the first issue is not the case. What needs to be done? I have not been able to find certain settings required for the SPI connection, like the parameter settings for the SPI connectivity in the .ioc

Kind regards,

Joey

[JNieu.1]

Added my file for the above question.

[Ulysses HERNIOSUS]

Hi Joey,

The ST25R95 and CR95 are the same in all respects relevant to you.

Best if you carefully review X-CUBE-NFC3 for the required settings of SPI, etc.

If you have done so, and it still doesn't work, then please provide a logic analyzer trace of your connection to the 95 ( CN5.1-6, CN9.3 of NFC03.).

Regards, Ulysses

[JNieu.1]

Hello Ulysses,

I have reviewed the X-CUBE-NFC3 settings and I have set mine the same.

Also I have added logic analyzer traces of my connection. Since I am unable to get all the signals at the same time I will have my SS (CS) signal as the trigger on both occurances. The first screenshots (SPI Interface) are the standard MOSI/MISO/CLK and SS signals. The other screenshots are the other signals IRQ_IN, IRQ_OUT.

After about 2 ms (Even though I think these times are not really significant) the G070B will start retrying the same routine for a few times. I think it is set in the code that it has to attempt it a couple of times.

Kind regards,

Joey

[Ulysses HERNIOSUS]

Hi Joey,

I think your CS line is not properly controlled (maybe configured to be controlled by HW block but I think we need it software controlled):

I see two single bytes <03> <03> being written in your case and in our software this is written in one frame: <03 03>. I guess this can be the reason.

Please check.

Regards, Ulysses

[Ulysses HERNIOSUS]

Hi,

didn't see SSI0 in your traces. Please check that as well.

Ulysses

P.S.: + second screnshot

[JNieu.1]

Hello Ulysses,

I have set my CS line to be controlled by software, (assuming it's the setting called Hardware NSS Signal which I set to Disable).

Which signal do you mean with SSIO?

I've added two screenshots, the first screenshots shows the same as last time but now in a single screenshot as I got my hands on a Logic Analyzer with more ports. The second screenshot is the pin layout as given in de user manual for the CR95HF.

Kind Regards,

Joey

Edit: Also on advanced parameters the NSS Signal Type is set to Software.