CLRC663 set error flag in IRQ register when writing data to NTAG210

[SasWin]

Setup: I use the Murata Tag LXMS33HCNK-171, which uses the NTAG210_NTAG212 (NTAG210)

            The reader IC is the CLRC663 .

            I don't use the software library and communicate to the tag without library based on                    application note AN12657. 

I am able to read the tag UID and all memory content from the tag without any errors. But when I want to write to the tag and check the IRQ register whether transmission and receive complete flag are set, the error flag is set as well. Also the data register still contains the data which should be written to the tag and not a ACK or NAK. 

Between transmission start and reading the data register I have a timeout ~5 ms (I know the maximum timeout is 10 ms) but I stop waiting as soon as IRQ register reports an error. 

My time delay loop is almost the same as the anticollision example from Vogtberg, Date 11.12.2019.

Did I forget any additional timeouts or protocol specific details? For example in ISO15693 I have to send an EOF after a certain time delay after the the actual write command. 

Because the write command is not mandatory in ISO14443-3 protocol, I can't find any further details except the timings given in the NTAG210_NTAG212  datasheet. 

Kind regards 

Sascha 

[EduardoZamora]

Hello @SasWin

Hope you are doing well.

According to CLRC663 plus Data Sheet, Section 8.1, the bit ErrIRQ in register IRQ0 indicates an error detected by the contactless UART during receive. This is indicated by any bit set to logic 1 in register Error (refer to Section 9.6.1).

Please consider that our support scope is limited to the usage of our recommended NFC Reader Library and supported MCUs from our portfolio. Implementation on third-party platforms is out of our support scope, and must be done by the user based on the information provided in CLRC663 plus family and NTAG 210/NTAG 212 product pages.

Regards,
Eduardo.

[SasWin · Accepted solution]

I was able to solve the problem above, which was caused due to wrong crc settings (I forgot to deactive crc appended to data on rx side setting for write command) which causes an crc error.