NFCのトピックPN7160 error read Mifare Classic

PN7160 error read Mifare Classic

amatteo78 — Fri, 04 Apr 2025 09:20:06 GMT

Good morning,
I am using the PN7160 chip in a project with an STM32MP157F. I'm working with the libnfc-nci library, but adapted to use libgpiod version 2.x. I'm experiencing an issue when reading a Mifare Classic badge.
If I enable logging (which introduces some delay), the badge is always read successfully on the first attempt. However, if I disable logging, the badge is only read after several attempts.

Our badge must be read from a protected sector, so authentication is required first.
I noticed that after the authentication command, I get the following sequence:

R 0x28 0x60 0x06 0x03 R 0x28 0x01 0x00 0x01 R 0x28 0x00 0x00 0x02 R 0x28 0x40 0x00 -> authentication successful (if it fails, it returns 0x03) W 0x28 0x00 0x00 0x03 0x10 0x30 0x04 R 0x28 0x60 0x06 0x03 R 0x28 0x01 0x00 0x01 R 0x28 0x00 0x00 0x12 R -> sector 0 block 1

When logging is enabled, there is a delay of about 6 ms between these two steps:

R 0x28 0x40 0x00 W 0x28 0x00 0x00 0x03 0x10 0x30 0x04

However, without logging, just 1 ms later a different write is triggered that breaks the sequence:

W 0x28 0x21 0x06 0x01 0x01

I don't understand why this happens. Besides introducing a manual delay in my reader application, I would like to understand the root cause more deeply.
I’m attaching two captures from a logic analyzer showing the described behavior.

Thank you

M.

Re: PN7160 error read Mifare Classic

jimmychan — Wed, 09 Apr 2025 05:12:14 GMT

Base on your information, it is hard to determine what is the issue. It is better to compare the log with your code together to debug what is it happen.

Re: PN7160 error read Mifare Classic

amatteo78 — Fri, 11 Apr 2025 19:09:36 GMT

Hi, by checking which debug logs were solving the issue, I discovered that the ones in the file NfccAltI2cTransport.cc were responsible. Inside the Read function, at the beginning and the end, there were these logs:

NXPLOG_TML_D("%s Enter", __func__); NXPLOG_TML_D("%s exit", __func__);

These are the logs that, somehow, were solving the problem. I’m not exactly sure why, and I’d like to better understand the behavior. So I recreated a function to simulate the same behavior without actually logging:

void EmulateLogDelay() { pthread_mutex_lock(&wait_log_mutex); volatile int sum = 0; for (int i = 0; i < 100000; ++i) sum += i; pthread_mutex_unlock(&wait_log_mutex); }

And now everything works perfectly, reading the badge correctly on the first try every time. Essentially, I had to create a delay — but not just a simple wait. It required a for loop and a pthread_mutex lock, exactly like the original log system does.

Do you have any idea why this happens? What’s going on in that moment that alters the following write behavior? Of course, if I understood the driver logic better, I could probably come up with a cleaner solution — maybe using a semaphore — but first, I need to understand what exactly needs to be awaited.

If you're interested, I’ve published a fork of the libnfc_nxp driver on my repository with support for libgpiod 2.x and this fix included.