CR95HF stops responding to UART

[chichkinei]

I use CR95HF with UART communication for some applications. I notice that occasionally (seemingly at random) the CR95 will stop responding to any UART commands. I send an ECHO and receive no response. I have experienced this with several of my own designs as well as with X-NUCLEO-NFC03A1 development board

On the rare occasion that I catch this and am able to troubleshoot I have tried cycling power to the chip. This usually fixes it, but not always. Sometimes I have to leave power off for minutes before it will work again.

I began suspecting that the issue was temperature dependent as the problem only seems to occur after ~1 hour of being powered up. I tested heating and cooling the device while sending ECHO commands but could not reproduce the problem at all.

My best guess now is that the problem stems from the crystal oscillator. I noticed that the oscillator is not always running during normal operation. Perhaps it has trouble starting up in some scenarios?

Is there any known issue with the UART interface? I notice it was removed on newer ST25 chipsets. Is there anything else I can test to troubleshoot this further?

I appreciate any insight,

Ivan

Edit:

I was able to reproduce this by temporarily shorting one side of the oscillator to ground. After removing the short, it resumes oscillation but the UART interface in non-functional until a power cycle.

Obviously, this is not how the problem occurs in reality, but I believe it happens by a similar method where the clock gets disturbed for whatever reason.

Is there any way to recover from this state that does not require cycling power?

[Brian TIDAL]

Hi Ivan,

Can you share some details about how you reproduce this issue on X-NUCLEO-NFC03A1 expansion board? On my side, I had the X-NUCLEO-NFC03A1 in UART mode polling tags for hours without any specific issues.

Is your PCB inside a closed casing? Is the ambiant temperature high?

Can you also share details about your firmware implementation:

• do you use the X-CUBE-NFC3 firmware library or your own implementation from the datasheet?
• in normal operation mode, the HF oscillator is supposed to stay ON, do you use the Idle command and low power modes of the CR95HF? How have you monitored the HF oscillator?
• which UART baud rate do you use? Do you use the BaudRate command to change the default baud rate?
• which MCU is used? STM32? Do you have a watchdog that may reset the MCU and may causing CR95HF and MCU being unsync'ed? Is the MCU UART Overflow flag monitored so that byte loss can be detected / recovered?
• when resetting the MCU, do you have an HW mechanism to power cycle the CR95HF or a FW mechanism to empty the CR95HF FIFO? See CR95HF - Reset IC using UART discussion about host and device being unsync'ed.
• can you describe the CR95HF startup sequence implementation?
• can you describe the tag polling implementation: which protocols are used ? do you have a dense polling loop (gun machine with RF mostly always ON) or a polling loop with delays? Is the tag detector being used?

Can you attach a logic analyzer on the UART and provide a trace?

Rgds

BT

[chichkinei]

Hi Brian,

Thanks for your reply. I believe the UART Reset workaround you provided fixes this issue for me. Here is some more detail about my test setup:

X-NUCLEO-NFC03A1 is connected to PC via FT232 USB-UART bridge. The PC sends Echo command (0x55) every ~100 ms.

To reproduce the issue, I briefly short the crystal tuning capacitor, C16. Sometimes, it takes several attempts for the failure to occur.

Now, the module will stop responding to Echo commands.

As you mentioned in the other thread, this is probably due to the UART becoming unsynchronized. I tried the workaround of sending 528x dummy bytes and this resets the UART and brings it back to a working state.

• In my application, the PCB is in a rather noisy environment but we have done out best to shield it.
• Ambient temperate reaches ~30 C maximum
• I have a custom implementation of the communication library, but I only use basic commands: Echo, Idn, select ISO15693, RdReg, WrReg.
• Regarding the crystal stopping oscillation during normal usage, I may have been mistaken. I noticed this a long time ago, but have not been able to reproduce it in my recent tests so it's possible something else was going on at the time
• I use default baud rate.
• The MCU is a NXP K24, but I do not think it's relevant. The MCU is not resetting, but it's possible the UART is going out of sync. I have not been able to capture a UART trace in the real environment when this failure happens
• The only startup sequence is select ISO15693
• There are lots of delays in the polling loop as the PCB is controlled with a Python script from PC. The tag detector is not being used.

I have captured a UART trace from the test setup I described above, but there is nothing interesting. The module simply stops transmitting from the UART after I induce the failure.

Anyway, I will implement the UART buffer reset trick in my applications and see if that is able to restore communication in all cases. I have a feeling there is something else going, since as previously mentioned, even power cycling does not always fix it.

Thanks for you suggestion,

Ivan