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

[JMilk.1]

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!

[Brian TIDAL]

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

[JMilk.1]

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]

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]

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]

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]

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

[JMilk.1]

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]

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

[JMilk.1]

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.

[Brian TIDAL]

Hi

st25r3916Initialize is a function inside st25r3916.c.

I suggest to put a breakpoint on it and to step inside. You should enter inside #ifdef ST25R_SELFTEST part of this function, in particular in the /* Check IRQ Handling */ part. If this returns ERR_TIMEOUT, this means the IRQ is not properly handled.

Rgds

BT