OM27160 i2c problem

[amatteo78]

I'm testing the PN7160 using EVK OM27160, for now, I'm communicating with it using the I2C tool. I connected SCL and SDA to the I2C-1 bus, then used 0V on GND and 3.3V on VDD and VBAT. I also used three pins for VEN, IRQ, and FWDWNL, but only VEN is high at 3.3V, while the other two are at 0V.

If I keep IRQ connected to the bus, i2cdetect doesn’t find anything. However, if I disconnect the IRQ pin, I see an address 0x28 appearing and disappearing. When I try to communicate using a command like i2cset -y 1 0x28 0x00, I see 7 bits with 0x28 on the oscilloscope, followed by a 0 bit for write, but then, when I expect the ACK bit to be 0, it is instead 1, and the communication stops, as if the PN7160 is not responding.

Now im starting with compile this lib https://github.com/NXPNFCLinux/linux_libnfc-nci/tree/NCI2.0_PN7160 but I don't understand why on bus I see address appear and disappear ?

What do you think I might be doing wrong? How did you solve it?

Thanks a lot!

[jimmychan]

Do you try to read/write by using the I2C? 

I use the i.MX6ULL EVK connect to PN7160. The I2C communication is good.

FYI. i.MX6ULL EVK running Yocto Linux + PN7160 - NXP Community

[amatteo78]

Thank you very much for your response. I switched to using transport mode 0x02 directly instead of the kernel driver mode 0x00, and now it seems to work better. Occasionally, it still freezes, but it might be related to access to the /sys/class/gpio class. On my board, I’m already using kernel 6.6, and I recompiled it with that class enabled since libnfc-nci relies on it to access the pins.

I also found a document explaining how to make the library compatible with the new GPIO access method via gpiochip (libgpiod) at this link:
https://community.nxp.com/t5/NFC-Knowledge-Base/Porting-PN7160-NCI2-stack-to-Raspberry-Pi-5-OS-Bookw...

I tested it on a Raspberry Pi 5, and it works. Now I need to try it on the other board, which is an STM32MP157F-DK2, to see if it stops freezing.

However, I still have an issue. In my project, I need to read sector 1 at block 0 of a MIFARE Classic 1K card, obviously with authentication. I wrote a small C program using the libnfc-nci library. I authenticate successfully and then read the sector, but occasionally, the first byte returns FF instead of the correct value. Other times, it returns correctly.

I don't understand whether this could be interference on the bus, but the strange thing is that it always affects that specific byte, never the others. I tried using an oscilloscope to analyze the signal, but the trace is too long, and I can't capture the relevant part. A logic analyzer would be helpful, but unfortunately, I don't have one available.

What could I try?

Best regards.

[jimmychan]

You could try more examples here:

GitHub - NXPNFCLinux/linux_libnfc-nci_examples: Examples of use of the linux libnfc-nci stack

And the demoapp

GitHub - NXPNFCLinux/linux_libnfc-nci at NCI2.0_PN7160

[amatteo78]

Hi,
I'm continuing my tests with a Raspberry Pi 5. The libnfc-nci library seems to be working, but my application, which tries to read a block in sector 1 after authentication, sometimes reads the first byte incorrectly, and other times fails authentication altogether.
I also tried using the nfcDemoApp in poll mode, and here too the returned data varies from read to read. Below is an excerpt:

Waiting for a Tag/Device...
NFC Tag Found
Type : 'Type A - Mifare Classic'
NFCID1 : '91 CB 32 00 '
NDEF Content : NO, mode=1, tech=8
Mifare Authenticate command sent
Response :
00
Mifare Read command sent
Response :
AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55
Mifare Write command sent
Response :
00 0A 14
NFC Tag Lost

Waiting for a Tag/Device...
NFC Tag Found
Type : 'Type A - Mifare Classic'
NFCID1 : '91 CB 32 00 '
NDEF Content : NO, mode=1, tech=8
Mifare Authenticate command sent
Response :
03
Mifare Read command sent
Response :
FF
Mifare Write command sent
Response :
10 B2
NFC Tag Lost

What could be the issue?
Thanks,
M.

[amatteo78]

Hello, I add a log keep during error read, I found "Mifare Error in payload response".
I attach log file.

Thanks

M.

[amatteo78]

Hello,

After applying some fixes to my app, where I now only write the bytes returned by the function, I noticed that in the auth request, which usually returns 1 byte, I get 00 if it's OK or 03 if it fails.
On the other hand, when reading a sector, I expect the response to always be 16 bytes, but when the function fails, it returns a response with a length of just 1 byte.

I noticed that whenever a read fails, I see the following lines in the logs (after enabling them):

NxpNci: RF Interface = Mifare Enable MifareExtns
NxpNci: RF Interface = MIFARE
NxpNci: Protocol = MIFARE
NxpNci: Mode = A Passive Poll

What could this indicate?
Could this help you understand what's going wrong?

Thanks

[jimmychan]

It depends which card are you used. You could read the datasheet. e.g. MIFARE Classic EV1 datasheet.

MIFARE Classic EV1 1K - Mainstream contactless smart card IC for fast and easy solution development

Check the authentication process and the response code table.

[amatteo78]

Problem solved. I found out that some debug code I was using between the authentication and reading phases was introducing a delay that caused the read to fail. In the suggested document, I saw that the timing requirements were very tight. I fixed the code, and now the reading works perfectly.

Thanks

M.