Esteemed Colleagues,
We are using PCA10040 (1.2.4 2018.16) to develop a customized NFC Type 2 TAG.
SDK 15.0.0 was used because we needed to work with hal_nfc_t2t.c instead of
the very restrictive t2t library found in 15.3.0.
The problem arises when we disable the CRCMODERX and PARITY bits on the
RXD.FRAMECONFIG register.
I was under the impression that setting both CRCMODERX and PARITY bits to 0
should allow me to see the RAW NFC received frames with both the parity bits
and the CRC16 bytes in tact and not yet removed from the buffer.
However, this is not the case at all.
Here is an example of a HALT CMD received when RXD.FRAMECONFIG
PARITY BIT was set to 1 and CRCMODERX BIT was set to 0:
(4 Bytes Received)
0x50, 0x00, 0x57, 0x9A
CMD = 0x50, 0x00 <-- This command is correct
CRC16 = 0x57, 0x9A <--- This CRC16 is wrong, it should be 0x57, 0xCD as per iso14443a
It gets worse when both both CRCMODERX and PARITY bits are set to 0.
Here is the same HALT CMD received:
(4 Bytes + 4 Extra Bits Received)
0x50, 0x01, 0x5E, 0x69, 0x06
When I manually try to remove the parity bits...
(get 32 bits from the first 4 bytes)
01010000000000010101111001101001
(get 4 bits from the 5th byte)
0110
total 36 bits : 010100000000000101011110011010010110
Every 9th bit is a parity bit they appear to be correct as well.
01010000 0 00000010 1 01111001 1 01001011 0
But the actual CMD and CRC16 bytes now becomes:
CMD = 0x50, 0x02 <-- This command is now different ???
CRC16 = 0x79, 0x4B <-- This CRC16 is wrong. It shoud be 0x45, 0xEE
I have verified using a Proxmark 3 NFC Packet Sniffer that in both
cases described above the actual CMD sent by the Card Reader is:
0x50, 0x00, 0x57, 0xCD
My main objective is to be able to manually process incoming RAW NFC frames
after the emulated t2t tag reaches the ACTIVE state.
I want to be able to remove the parity bits manually and check the CRC16
bytes manually since we will be customizing the protocol to our needs.
Any advice would be appreciated.
Best Regards,
Brad Roberts
