nfcpy

Reading ST M24SR tags

Asked by James

Posting this in case anyone else is having trouble with the same tags:

I was unable to read ST M24SR64 tags (containing a URI NDEF) with the 0.9.2 or trunk branch.

The output log:
INFO:nfc.clf:searching for reader with path 'usb'
INFO:nfc.clf:using ACS ACR122U PICC Interface at usb:002:004
ERROR:nfc.tag.tt4:while reading ndef: Exception('capability container not found',)
Type4Tag ATQ=4200 SAK=20 UID=028400010aad4f ATS=0578009002

I confirmed using the ST M24SR Android application that the device does have a capability container. The NFC Tools app is also able to read the data.

The dev-tags branch is able to read & write the tags properly.

However, the dev-tags branch does not seem properly to close the ACR122U reader, so I was unable to read/write multiple tags sequentially. The solution was to add:

self.chipset.transport.close()

to the end of Device.close() function in pn532.py. I'm not at all sure if that's a proper fix, but it seems to work.

Question information

Language:
English Edit question
Status:
Solved
For:
nfcpy Edit question
Assignee:
No assignee Edit question
Solved by:
James
Solved:
Last query:
Last reply:
Revision history for this message
Stephen Tiedemann (stephen-tiedemann) said : 		#1

Thanks for spotting this. You've applied the correct solution. With revision #404 (pushed 2015-07-06) this got fixed in the dev-tags branch.

Revision history for this message
James (t-james-6) said : 		#2

Just to clarify, because my post references two separate problems:

The M24SR tag handling was fixed in #404 (?)

The latest revision (404) of pn532.py in dev-tags does not properly close the usb port. Here is the change that was necessary:

--- nfc/clf/pn532.py
+++ pn532.py
@@ -198,6 +198,7 @@
             time.sleep(0.001)
             self.chipset.transport.baudrate = 115200
         self.chipset.power_down(wakeup_enable=("I2C", "SPI", "HSU"))
+ self.chipset.transport.close()

     def sense_tta(self, target):
         """Search for a Type A Target.

Revision history for this message
Stephen Tiedemann (stephen-tiedemann) said : 		#3

My fault, confused pn532 with pn53x. I've now cleaned all <driver>.close methods to properly call down the hierarchy and eventually get to chipset.close. This with revision #422. Please let me know if it works as expected.

Revision history for this message
James (t-james-6) said : 		#4

Seems to work now - thanks!