Read/Write to STmicro ISO 14443-4 tags using X-Nucleo and raspberry pi

JMilk.1 · ‎2022-06-20

Hi all,

I'm trying to read and write values to an STmicro tag(ST25TA02KB-D, ISO 14443-4) using the X-Nucleo board from a python program. I've tried a number of approaches(waveshare pi hat, standalone PN532 modules, using libnfc and adafruit libraries, to list) but none really work and it's honestly a little out of my depth.

Currently I've built the Linux nfc polling demo included with the X-Nucleo board, but even that fails to run(see attached)

If I had resources or python examples using any of these systems, I could probably figure it out, but all the support I've found seems to apply mainly to mifare classic cards.

If anybody has experience or pointers for any of this I'd be quite grateful to hear it!

JMilk.1 · ‎2022-07-08

Thank you! I'm a junior EE mostly dealing with hardware, but we're tagging in one of our developers to assist, so hopefully that'll be less of an issue.

What we're trying to do is automate the process of reading the memory and writing a short text file- essentially a model number. Unfortunately we're locked into the ST25TA at this point, and revising the board isn't a possibility, though there are some alternative options to interface with it, namely a waveshare PN532 NFC hat, or a standalone PN532 module.

Solution update: I've found that NFCpy(https://nfcpy.readthedocs.io/en/latest/topics/get-started.html#installation) has support for T4T tags- we're using the PN532 module connected over UART, and are now able to read and write text to the ST25 tag.

I'm tagging this as best for anyone doing the same thing in the future, Thank you all for your help!

View solution in original post

Brian TIDAL · ‎2022-06-20

Hi,

which x-nucleo- board do you use?

If using the X-NUCLEO-NFC06A1, I would suggest you have a look to STSW-ST25R013 package.

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.

JMilk.1 · ‎2022-06-21

Correct, it's the NFC06A1!

I've been using the software(STSW-ST25R013) and guide(https://www.st.com/resource/en/user_manual/um2548-linux-driver-for-the-st25r3916-stmicroelectronics.pdf) listed on that page. I made a fresh build in hopes there's a step I missed, but encountered the same error. I've included screenshots of the whole process below.

Extraction:Building:

Testing Program:

Ulysses HERNIOSUS · ‎2022-06-22

Hi,

it seems GPIO7 cannot be allocated by our nfc application. Likely someone else is using it. You could investigate (/sys, gpio tools) who is using the device and likely it will give you hints how to disable the blocking function. However I don't have all the tools currently at hand to guide you in detail through the process.

The other alternative is to go as closely as possible to our original setup. Which version of the RaspBerry PI are you using and which version of Raspbian?

BR, Ulysses

Ulysses HERNIOSUS · ‎2022-06-22

Hi,

doing some more research I find attached updated readme.txt which explains the problem and provides a solution. Please check it out!

Regards, Ulysses

JMilk.1 · ‎2022-06-27

Thank you so much!

We're using a raspberry pi 4 with Raspbian 11, as the version used in the documentation isn't supported by our pi. After following the updated readme(thank you) and a few restarts we no longer get the GPIO error. The program runs and the led's(F, B, A, and TX) on the nucleo board begin flashing.

However, it doesn't seem to be picking up any of the nfc tags(known good ST25's and mifare fobs) placed on the antenna pcb. This doesn't return any sort of error to diagnose, it just continues scanning.

I'm currently rechecking the jumper settings and trying a fresh version of raspbian, included is a snip showing the pi's version info and the program's current output.

Brian TIDAL · ‎2022-06-28

Hi,

I suspect that the ST25R3916 interrupt is not properly seen by the RPi.

I would suggest to check that ST25R3916 is properly connected to RPi GPIO 7 (CE1). If using an ARPI600 interposer, make sure to have the proper jumper configuration (ARPI600 A0 should be connected to RPi CE1). Do you use an ARPI600 interposer or "flying" wires?

I also suggest to define ST25R_SELFTEST in your build: this define adds extra checking during initialization of the ST25R3916. In particular, this checks the proper handling of the ST25R396 IRQ: see st25r3916Initialize (an ERR_TIMEOUT error is returned if the IRQ i not properly handled)

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.

JMilk.1 · ‎2022-06-28

I'm using the ARPI600 configured per this document here- https://www.st.com/resource/en/user_manual/um2548-linux-driver-for-the-st25r3916-stmicroelectronics.pdf - P25...CE1 are connected to A5...A0, and I've double checked all the hardware to the above guide.

I ran GPIO readall to get an overview and I've included it here. Pin 7 seems to be on as an input.

Here's the relevant changes I've made to config.txt as well, from updated readme

It may be useful(?) that reassigning the interrupt pin to another one(say GPIO 6) doesn't work as a fix in this instance, throwing a similar GPIO init error- which I think supports your analysis.

This may be a dumb question, but how would I go about defining ST25R_SELFTEST in the build?

Brian TIDAL · ‎2022-06-28

Hi,

in Linux_RFAL_st25r3916_v2.2.0\linux_demo\CmakeLists.txt, just change

add_definitions(-DST25R3916)

by

add_definitions(-DST25R3916 -DST25R_SELFTEST) then relaunch cmake and then make.

You can also modify the platform.h file to add #define ST25R_SELFTEST and then make.

Using the debugger, make sure the code inside the #ifdef ST25R_SELFTEST in st25r3916Initialize is properly executed and check the result of the interrupt selftest.

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.

JMilk.1 · ‎2022-06-29

Okay, thank you!

I've tried both of these approaches, editing cmake, then platform.h- shown below:Neither produces any visible change, but I may be doing it wrong. I made a build with "cmake -DCMAKE_BUILD_TYPE=Debug .." per the readme file, here's what I see in the GDB text ui

Where should I be looking for st25r3916Initialize? Is it a function somewhere or it's own program within the package?

Thank you greatly,

JM

Edit:

From what I can tell, this is the point at which it fails, inside main.c

The highlighted portions there, and it explains the blinking behavior I've been seeing.