Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ACR122S is it still supported and working #660

Open
marcosgatcomputer opened this issue Nov 1, 2021 · 0 comments
Open

ACR122S is it still supported and working #660

marcosgatcomputer opened this issue Nov 1, 2021 · 0 comments

Comments

@marcosgatcomputer
Copy link

Hello,

Last week a second-hand ACR122L NFC reader came into my hands. This reader is basically the same as ACR122S with a small two-line screen. And it comes with an old-school SUB DB-9 connector so I had to get a USB to RS-232 converter.

Reading the protocols for both models I concluded the ACR122L should work out of the box with libnfc. Unfortunately, it didn't.

After messing around a bit with the code I noticed the problem was coming from the part where the firmware is checked against the reader's (./libnfc/drivers/acr122s.c line 390):

if (! acr122s_build_frame(pnd, cmd, sizeof(cmd), 0x48, 0, NULL, 0, 0)) {
    return NFC_EINVARG;
  }

I thought the NULL was a bit odd. Looking at the function (line 304) this is what I found:

acr122s_build_frame(nfc_device *pnd,
                    uint8_t *frame, size_t frame_size, uint8_t p1, uint8_t p2,
                    const uint8_t *data, size_t data_size, int should_prefix)
{
  if (frame_size < data_size + APDU_OVERHEAD + should_prefix)
    return false;
  if (data_size + should_prefix > 255)
    return false;
  if (data == NULL)
    return false;

This last conditional makes the function blow up and it is always part of the initialization of the device.

Is somebody else using the ACR122S driver able to confirm the current code base is working?

I was able to make my reader work just by removing this conditional and editing the device name on lines 493 and 633 to the name of my device, which was "ACR122L310SAMA" instead of the default "ACR122S". I got the correct tag name by running the sample code provided by the manufacturer as the output of the ACR122_GetFirmwareVersion() function. It was also useful to add a snippet calling ACR122_GetBaudRate() to make sure the device was set for the default 9600 bps.

Feel free to close this issue at your convenience. I think most users went into the USB direction some time ago but I wanted to keep a record as a heads-up just in case somebody else gets one of these readers (or future-me runs into this issue again).

Thank you for your efforts with this library.

Cheers!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant