The problem occurs in the following succession of events:
* Emit commands returning an answer larger than 16 bytes
* Re-enumerate USB devices without power cycle, e.g. a warm reboot of the PC
The bug can be reproduced for testing purposes with usbreset.c from
https://askubuntu.com/questions/645/how-do-you-reset-a-usb-device-from-the-command-line#661
$ lsusb|grep NFC
Bus 001 Device 010: ID 04e6:5591 SCM Microsystems, Inc. SCL3711-NFC&RW
$ sudo ./usbreset /dev/bus/usb/001/010
Resetting USB device /dev/bus/usb/001/010
Reset successful
$ echo -e "4a 01 00\n423000" |pn53x-tamashell
$ sudo ./usbreset /dev/bus/usb/001/010
Resetting USB device /dev/bus/usb/001/010
Error in ioctl: No such device
$ lsusb|grep NFC
... device disappeared
In the example above, reading 4 pages of a MFUL corrupted one single byte.
The entire buffer can be corrupted e.g. with fast-reading a MFUL EV1:
$ echo -e "4a 01 00\n423a0013"|pn53x-tamashell
The problem occurs in the following succession of events:
* Emit commands larger than 17 bytes
* Re-enumerate USB devices without power cycle, e.g. a warm reboot of the PC
The bug can be reproduced for testing purposes with usbreset.c from
https://askubuntu.com/questions/645/how-do-you-reset-a-usb-device-from-the-command-line#661
$ lsusb|grep NFC
Bus 001 Device 010: ID 04e6:5591 SCM Microsystems, Inc. SCL3711-NFC&RW
$ sudo ./usbreset /dev/bus/usb/001/010
Resetting USB device /dev/bus/usb/001/010
Reset successful
$ echo 06000000000000000000000000000000000000 |pn53x-tamashell
$ sudo ./usbreset /dev/bus/usb/001/010
Resetting USB device /dev/bus/usb/001/010
Error in ioctl: No such device
$ lsusb|grep NFC
... device disappeared
After a DESfire operation SCL3711 will sometimes enter a state where
libusb-0.x is unable to fill config field in struct usb_device. The
USB device has to be power-cycled to restore a sane state.
This introduce a work around, by using hardcoded values for endpoints
and packet size when they are unavailable.
nfc.c:1244:19: warning: Dereference of undefined pointer value
for (int i = 0; nmt[i]; i++) {
^~~~~~
nfc.c:1256:23: warning: Dereference of undefined pointer value
for (int j = 0; nbr[j]; j++) {
^~~~~~
pn53x.c:1746:15: warning: Function call argument is an uninitialized value
*cycles = __pn53x_get_timer(pnd, pbtTxRaw[szTx + 1]);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The datasheet is wrong for the pn532_i2c. After having constant issues
with the device failing to respond on the bus and after contacting NXP
about this, it turns out 1.3 ms is too tight. The official timing spec
is unknown for now, but we tested 4 and 5 ms without problems. Thus we
have choosen 5 ms as a safe delay.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
Currently, we very occasionally can EXNIO errors from pn532_i2c_write() ->
i2c_write() -> write(). This may happen about once every 30 seconds.
Based from the kernel sources, EXNIO happens if the chip no longer
responds to its own address.
To make sure we do not loose any sent packets, we retry to send
PN532_SEND_RETRIES number of times. Since we miss 1 every 30 or so
seconds, doing 1 retry should be fine.
This might be considered a hack as the failure may be some other timing
related issue.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
The pn532 user manual states that after a i2c stop condition and before a i2c
start condition there should be a delay of minimally 1.3 milliseconds.
This is probably a limitation of the i2c peripheral or the firmware. In
any case, each i2c_read and i2c_write creates the packets which are
complemented with start/stop markers. It is thus required to take care
of timing in these two functions.
We solve this by wrapping the lower i2c_read and i2c_write functions for
the pn532, as this requirement is not for all chips.
Currently, we keep time using local variable, and thus the code is not
thread-safe. With libnfc being single threaded and only one instances of
libnfc can open a bus anyway, this is not yet a problem.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
The pn532 documentation differs slightly from the included ascii art
documentation on how a packet looks like. The preamble was omitted
however the postamble is mentioned. This patch adds the Preamble to the
ascii frame documentation.
The code later refers incorrectly to the start byte as the preamble.
This variable was renamed to more descriptively state that it is the
preambe and the start bytes.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
Currently we only inform the user with the error logging mechanism that
we received a different number of bytes than expected.
Thus in case of an error, we say that we sent/received -1 bytes. However
-1 indicates an error and errno is set to indicate the error state.
This patch extends the logging to also print the actual error.
Additionally the same debugging printing was added to read, which is now
silently returned to the caller.
Signed-off-by: Olliver Schinagl <o.schinagl@ultimaker.com>
When there is no tag on PN532 reader, the library
incorrectly processed call result and returned
NFC_ECHIP (chip error) instead of 0 (no targets
found).
