CR95HF - Reset IC using UART

[LM]

I have this NFC reader connected as slave using UART.

The IC normally works fine (using the UART StartUp Sequence), but some times stuck (this is another issue), If We try to get the ECHO command, never gets back the 0x55, means CR95HF is stacked, the only way to making work is to PowerUp.

I been trying to RESET the CR95HF using the PowerUp sequence (without PowerUp the IC) but I have no success.

is there any sequence to perform the Reset using the UART?

Thank you

[Brian TIDAL]

​Hi

the Reset command is only available through the SPI interface.  When using UART, only IC power cycle can reset the CR95HF.

Rgds

BT

[dcode31]

Hi @Brian TIDAL_O​ you've stated that the CR95HF, using UART, can only be reset with an IC power cycle. However, the CR95HF datasheet states the following;

If the user loses UART synchronization, it can be recovered by sending an ECHO command until a valid ECHO reply is received. Otherwise, after a maximum of 528 ECHO commands, CR95HF will reply with an error code meaning its input buffer is full. The user can now restart a UART exchange.

I have three questions, which may also help the original poster (@LM​ ) too.

1. Is this method of resting the UART true?
2. What error code (shown in the datasheet) would be sent back after sending enough ECHO commands?
3. After the error code is sent, what is the exact process to restart the UART exchange?

Thank you in advance for your time and consideration in answering my questions.

Best Regards,

Dion

[Brian TIDAL]

Hi,

here are some answers

1/ this is not a method that resets the UART. This is a way to recover when host and device lose synchronization. When the host (MCU) is reset, the CR95HF is not reset unless a power cycle is performed. Therefore, if the host is reset during an UART transmit, then the CR95HF UART buffer may be not empty when the host restarts:

• case #1: host reset occurs while CR95HF UART buffer contains CMD LEN and N data (N < LEN)
• case #2: host reset occurs while CR95HF UART buffer contains only CMD
• case #3: host reset occurs while CR95HF UART buffer is empty and the CR95HF is waiting for the next command
• case #4: host reset occurs while CR95HF processes a command

For case #1 and #2, host and device are unsync. In order to be able to communicate, it is needed to complete the current command with dummy data. This can be done with echo characters that will fill the UART buffer until LEN is reached (note: for case #2, the first 0x55 sent will be considered as the LEN parameter). Once the buffer contains the full command, it will be processed and response code will be sent. This response code can be ignored.

For case #3, the host and device are sync and the device will properly answer to the echo command

For case #4, the host and the device are unsync. The echo command will not be processed. After a certain time, the host will receive the answer of the current command. This response code can be ignored.

2/ In case a loss of synchronization between the host and the device and after sending enough 0x55 dummy data, the CR95HF sends the response code of the command. This response code can be ignored.

3/ nothing special is needed, just sent the next command. Anyway, I would recommend to sent ECHO then IDN then PROTOCOL SELECT Field OFF.

The following algorithm can be implemented at startup

set retry to max LEN value

send echo:

• case echo reply received --> continue the initialization sequence
• case timeout and retry > 0 --> retry-- and goto send echo
• case timeout and retry = 0 --> return init error
• case answer received but different from echo reply --> Empty the host UART receive buffer (read 528 data until a rx timeout occurs) and goto send echo

Anyway, the only way to have a robust init sequence is to power cycle the device when the host resets.

Rgds

BT