2020-07-27 04:15 AM
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
Solved! Go to Solution.
2020-08-14 04:20 AM
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
2020-08-14 05:21 AM
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
2020-08-14 05:54 AM
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
2020-08-18 02:34 AM
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
2020-08-18 02:39 AM
2020-08-19 07:45 AM
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
2020-08-20 02:21 AM
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
2020-08-20 06:02 AM
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
2020-08-20 06:03 AM
2020-08-23 11:55 PM
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.