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>
This patch allows for using the CMakefile to generate debian packages.
While CPack is far from perfect for generating debian packages, it is a
minimal change and quite helpful for quick deployment on debian based
systems.
Signed-off-by: Olliver Schinagl <o.schinagl@ultimaker.com>
Currently, we return false, and after turning set the bFailure state.
This is of course not possible.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
We use a variable, uiBlocks, to determine how many blocks to read/write.
Reading is actually done via a hardcoded 0xF value however.
Additionally, make uiblocks a const, as we use it as a constant and
change the page variable to uint32_t for consistency sake.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
When several tags are in range, nfc-mfultralight uses the lowest ID it
finds by default. This patch adds some code from nfc-list that lists the
tags in range whenever an operation is performed (r/w). Further more it
adds the --with-uid <UID> option to force reading/writing of a specific
tag.
The UID can be up to 10 bytes long and can be optionally separated by
colons or hyphens (MAC address style).
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
For some reason, 0cece94778 changed the argc count check to only show
the help if argc is 0. Obviously, argc is never zero, as the first
argument in argv is always the binary itself. Revert that and show usage
if there is no arguments supplied to the binary.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
The nfc-mfclassic utility will pick a seemingly random (the libnfc
default which seems to be the lowest UID). With the new (u|U) options
it is now possible to force a UID and thus write a specific tag, which
can be very useful if there are more then one tag visible.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
Currently the check on argc is done twice, once in each if branch. This
is silly and we can just check once and fail right away.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
- For cards that aren’t magic, system will refuse to attempt writing
to block 0 / 1
- Tested on Gen 1 & Gen 2 cards:
Gen 1
$ ./nfc-mfultralight w ul-test.dmp --full
NFC device: SCM Micro / SCL3711-NFC&RW opened
Found MIFARE Ultralight card with UID: 044e075ad42184
Writing 16 pages |................|
Done, 16 of 16 pages written (0 pages skipped).
Gen 2
$ ./nfc-mfultralight w ul-test.dmp --full
NFC device: SCM Micro / SCL3711-NFC&RW opened
Found MIFARE Ultralight card with UID: 044e075ad42184
Writing 16 pages |................|
Done, 16 of 16 pages written (0 pages skipped).
Non-magic
$ ./nfc-mfultralight w ul-test.dmp --full
NFC device: SCM Micro / SCL3711-NFC&RW opened
Found MIFARE Ultralight card with UID: 044e075ad42184
Writing 16 pages |
Unable to unlock card - are you sure the card is magic?
$
