Porting of CLRC663 from SPI to UART

[kv2]

Hello,

We have a working demo discovery example code for SPI, and we want to change the interface to UART.
We have made changes by selecting IFSEL0 and IFSEL1 to VSS as per the datasheet.

We have made changes in the BAL SPI so that it works for UART.

UART communication is working, as we verify that register read/write is happening.

The problem is with Interrupts, which are not getting cleared. We suspect FIFO overflow is happening.

Any idea how we can solve this issue ?

[kv2]

Hello @Daniel_Gutierrez , please find the response

• I would like to ask if you could please share more details about your setup such as: what is your current hardware configuration? Are you using the CLRC663 with a custom board or a modified CLRC663 plus NFC Development Kit?
  
  We are using custom CLRC663 hardware and it is connected to Host RaspberryPi. On the same custom CLRC663 board we have verified the SPI and card is getting detected. We have changed IFSEL0 and IFSEL1 to VSS for UART

•  would like to ask as well how are you connecting your host MCU to the UART interface and interrupt pin of the CLRC663? And what is the MCU host that you are using?
  
  We are following this document https://www.nxp.com/docs/en/application-note/AN11802.pdf for connection. This is for SPI, same we have done for UART as following
  
  CLRC663Raspberry Pi Pin Number (Pin Function)

  MOSI (RX)	8 (GPIO14)
  MISO (TX)	10 (GPIO15)
  SCK	NC
  SSEL	35 (GPIO19)
  CLRC_NRST	18 (GPIO24)
  IRQ	16 (GPIO23)
  IFSEL0	Ground
  IFSEL1	Ground
  Ground	6 (Ground)

  
  

  • It would be very helpful if you could please share a log of the UART commands sent to the CLRC663 as well as its response. Please share as well, all the code modifications that you made to the NFC reader library.
    Logs attached to logs.txt file
    code changes patch attached to uart.patch file
    
    

[Daniel_Gutierrez]

Hello @kv2, Good Day!

Unfortunately, support related to using the CLRC663 with a third-party host is very limited since this is not an NXP product.

However, in order to troubleshoot, I would like to ask, have you enabled the UART physical interface as shown in section 3.3 of the NFC Reader Library for Linux Application Note ?

I would also like to ask what did you observe to know that the interrupts are not being cleared?  Does the application have to actively clear the interrupt flags by calling the phDriver_PinClearIntStatus function?

It would be very helpful if you could please measure the UART TX and RX pins by connecting them to an oscilloscope or logic analyzer and please share a picture of the communication frame you get.  Consider that for proper serial communication the frame should look similar to the ones mentioned in figures 14 and 15 of the CLRC663 and CLRC663 plus Data Sheet.

My best regards,
Daniel

[kv2]

Hi @Daniel_Gutierrez 

Yes we have enabled the UART interface for the host and we got the /dev/ttyS0 node. I already inform that register read/write is happening and we are able to read version register also

For interuppt not cleared, we have probed the IRQ line and we saw the line becomes high after interrupt

Will check the UART Tx and Rx by probing the lines

Please check uart.patch file and let us know if we have to do any other configuration for UART.

[kv2]

Hi @Daniel_Gutierrez,

Did you get a chance to review the UART configuration attached in uart.patch file?

[Daniel_Gutierrez]

Hello @kv2, Good Day!

I was able to review the modifications made to the code, and they look okay. I would recommend ensuring that the PHDRIVER_PIN_IF3 stays HIGH all the time during execution, as this is needed when using UART interface.

Regarding the interruption pin, does it become HIGH and then low? Or does it stay HIGH all the time after the first interruption? Can you please confirm this with a logic analyzer?

Did you experience the application getting stuck in the interrupt service routine (pRFISRCallback) after the first interruption? If this is the case, please share the definition of your phDriver_PinClearIntStatus().

It would still be very helpful if you could please send a picture of the UART pins showing the communication frame with a logic analyzer.

My best regards,
Daniel

[kv2]

Hi @Daniel_Gutierrez 

• I was able to review the modifications made to the code, and they look okay. I would recommend ensuring that the PHDRIVER_PIN_IF3 stays HIGH all the time during execution, as this is needed when using UART interface.
  
  Yes it is always high all the time.
  
  

• Regarding the interruption pin, does it become HIGH and then low? Or does it stay HIGH all the time after the first interruption? Can you please confirm this with a logic analyzer?
  It is transitioned from low to high then it becomes always high.

• Did you experience the application getting stuck in the interrupt service routine (pRFISRCallback) after the first interruption? If this is the case, please share the definition of your phDriver_PinClearIntStatus().
  No application does not stuck in the (ISR pRFISRCallback), we do not write the definition for this phDriver_PinClearIntStatus(), it is just like same as in SPI case.
  
• It would still be very helpful if you could please send a picture of the UART pins showing the communication frame with a logic analyzer.
  logic_analyser.jpg picture is attached
  yellow line represent RX to the CLRC
  green line represent TX of the CLRC
  
  

[Daniel_Gutierrez]

Hello @kv2, Good Day!

Please share a picture of the communication frame in which the configuration of the oscilloscope or logic analyzer allows to interpret the commands sent and the response can be appreciated.  Something similar to this but for the UART interface:

When you say that the interrupts are not being cleared, do you only refer to the IRQ pin not going LOW? Or did you observe the interrupt requests of the IRQ0 and IRQ1 register of the CLRC663 not being cleared? If so, how were they configured? And how did you test this?

Did you only modify what is shown in the patch file? Did you make any other modifications to register configurations or the initialization of the reader?

I would like to ask, how are you testing the example? Have you put an NFC tag close to the antenna of the reader and observed what happened after?

When using the SPI interface previously did you get the expected log?

Are you able to observe this log when using the UART interface?

Please consider that support in this specific scenario is very limited, since custom hardware is being used along with a third-party device. The related resource we offer is the NFC Reader Library for Linux Application Note, however, it is only for demonstrating purposes and any other implementation is up to the customer.

My best regards,
Daniel

[Daniel_Gutierrez]

Hello @kv2, Good Day!

Thank you very much for your interest in our products.

I would like to ask if you could please share more details about your setup such as: what is your current hardware configuration? Are you using the CLRC663 with a custom board or a modified CLRC663 plus NFC Development Kit?

I would like to ask as well how are you connecting your host MCU to the UART interface and interrupt pin of the CLRC663? And what is the MCU host that you are using?

It would be very helpful if you could please share a log of the UART commands sent to the CLRC663 as well as its response. Please share as well, all the code modifications that you made to the NFC reader library.

My best regards,
Daniel