[BUG] drivers/contactless/PN532: Incorrect UID Readings, Timeouts, and Documentation issues

[keever50]

Summary
The PN532 driver for NFC/RFID tag reading appears incomplete, undocumented, and unreliable. It exhibits multiple issues, including incorrect UID readings, broken timeout handling, and limitations on UID length.

Environment
Hardware: PN532 NFC reader via SPI
MCUs tested: STM32F4, Raspberry Pi Pico (with added local driver support)
Test code: Pastebin link

--Issues Observed--

Incorrect UID Readings
The first byte of the UID is unique, but the rest remain the same across all NFC tags.
This suggests a possible bug in the driver’s UID parsing or response handling.

Polling for New Cards Fails
When polling for new NFC cards, the driver frequently returns timeout errors.
Timeout settings appear to be non-functional.

UID Length Restriction
The driver only returns 4-byte UIDs, whereas the PN532 is capable of providing longer UIDs.

Concerns and Next Steps
The driver is very old and poorly documented, making it difficult to diagnose and fix issues.
I have previously written a PN532 driver with similar (or more) functionality. Given the state of this driver, would it make more sense to fix these issues or port my own driver instead?

On which OS does this issue occur?

[OS: Linux]

What is the version of your OS?

Arch Linux x86_64, Kernel: 6.13.4-arch1-1

NuttX Version

Master

Issue Architecture

[Arch: all]

Issue Area

[Area: Drivers]

Host information

No response

Verification

• I have verified before submitting the report.

[acassis]

@keever50 probably they only use it with Mifare cards (it was contributed by Haltian people). Probably the driver needs to be extended to support NFC!

[keever50]

@acassis
I’ve tried it with the card types they support, but it didn’t work.
With NFC / RFID, i mean cards like Mifare, which is the card type i tested. ISO/IEC 14443-4 Type A to be exact.
To be fair, without documentation, I cannot be 100% sure if this isn't the intended way of doing it.
I do not mean to disrespect the contributors of this driver, I'm happy people are adding useful drivers to NuttX.

[acassis]

@keever50 yes, this is why I always ask people to submit a board profile and example application. Maybe you can try to ping Janne Rosberg https://nuttx.yahoogroups.narkive.com/jJC51Zvs/nfc-chips-support he still around and sometimes send email to the mailing list. Try to send a public email to the mailing list and add him as CC

[keever50]

Update on this:

I changed a ton of code. It was necessary.

Changes:

• Fixed UID reading,
• added possibility to develop support for other interface busses. (clearly marked and hints how to implement)
• added a place for IRQ requests (clearly marked and hints how to implement)
• improved (replaced) the frame handling,
• added checks for frame integrity (checking nearly all possible errors. Tested).
• added comments for self documentation
• added support for platforms (such as rp2040) that do not have SPI hardware bit order settings

I probably forgot some.

Todo:

• Add driver internal commands (relatively easy)
• Make the IOCTL commands compatible again with the old one (easy)
• Add documentation
• Add test app

Proof of progress:

Phone app shows serial code (UID) 07 3B C1 5F

PN532 frame returned. That is the UID

Nice, it is right there. Should be in memory now.

(not yet output to app)

[acassis]

Nice work @keever50!!! So now is it possible to interface with NFC cards and smartphone, right?
We don't have a Documentation about it (there are many references to NFC, but only about boards and MCUs supporting it), should be nice to have it with these images you posted here.

[keever50]

@acassis Thanks!

Currently with the state of this driver, you can only scan mifare cards.
However, the way i lay out the architecture, more target types will be possible.
Like smartphones, yes!
I'm trying to make it easier for future developers in case i dont implement it myself.

For the future:
There is a possibility that i have to look into expanding the NFC/contactless ioctl.h common section.
for example: set card type(mifare, others), set scan mode (act as: initializer, target, communication between two scanners(phone)).
Maybe even a command to switch the read/write() behavior.
Currently read() only reads UID from specifically mifare.
Would be super cool if you can switch modes to make it read/write() actual card contents.

[keever50]

@acassis whats your thought on this?
There are some ioctl commands that really need to be changed.
Such as PN532IOC_SEND_CMD_READ_PASSIVE which... does not take any arguments for some reason.
It should. It also requires a timeout, which is fixed to 0, which makes no sense either. But it is a crucial thing for this to function.
But yeah this makes it a breaking change, which isn't hugely welcome in NuttX. But this driver doesn't seem to be used from what i can see?

How big of a deal would it be if its interface changes? It is a challenge to work around it.

[raiden00pl]

A common and general interface would also be useful for contactless drivers. These drivers are another example where no one thought about portability and a universal interface. These drivers were added without much effort in API design. I will repeat my opinion once again: breaking change for things that are done badly is OK.

[acassis]

@keever50 @raiden00pl yes, in the past NuttX used to have a set of ioctl() for each drivers, but for standard interfaces like RFID (Mifare, NFC, etc) having a set of common ioctls makes more sense. It will make possible to have applications that work with all contactless drivers.

[keever50]

Update:

Common API is now proposed in issues.

PN532 is mostly complete and uses the common API. I will PR it once the common API is approved.

Here are some sneak peeks into the new PN532 driver:

[ This shows the test application (https://pastebin.com/sXzwUALk) output ]

[ This shows that the new PN532 has plenty ways of expanding its functionality ]