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.
