Skip to main content
L
LM.2
Visitor II
March 24, 2022
Solved

x-cube-nfc3 UART issues, passing initialisation but not detecting NFC tags.

  • March 24, 2022
  • 1 reply
  • 1297 views

Hey,

I have been using the x-cube-nfc3 demo for Nucleo-l496ZG 144 pin board along with a CR95HF. In SPI mode I can successfully initialise and read the ID from NFC tags. I attempted to change to UART mode by adding 

#define ST25R95_INTERFACE_UART 1

to platform.h. I also changed the macros in platform.h from huart1 to huart3 because it saved soldering of additional headers.

With these modifications the device initialises successfully over UART however I cannot get it to detect any NFC tags.

Are there any more modifications needed?

    This topic has been closed for replies.
    Best answer by Brian TIDAL

    HI,

    the SSI_0 (signal D9 on CN5 connector of the X-NUCLEO-NFC03A1 board) has to be set to low (see table 4 of the CR95HF datasheet) in order to properly select the UART interface during the startup sequence (see § 3.2 of the datasheet). Make sure the GPIO connected to SSI_0 is set to low in your configuration.

    On Software side, the UART interrupt has to be enabled and the HAL_UART_TxCpltCallback, HAL_UART_RxCpltCallback and HAL_UART_ErrorCallback have to be populated with  st25r95UartTxCpltCallback (resp. st25r95UartRxCpltCallback, st25r95UartErrorCallback). See https://community.st.com/s/question/0D50X0000B7YwL7SQK/how-to-use-uart-interface-instead-of-spi-with-xnucleonfc03a1-and-xcubenfc3-polling-demo for further details (it also provides a demo package based on X-CUBE-NFC3 2.0.0 that should help).

    st25r95Initialize() does 5 attempts to send an echo command with UART TX/RX in blocking mode. If the UART communication fails (no reply to echo command), the st25r95Initialize returns ERR_SYSTEM. If it returns ERR_NONE, it means your UART communication is OK. Then further communication uses UART TX/RX with interrupt mode. If this part is failing, make sure to enable the UART interrupt and to populate the callbacks.

    Note: You can enable ST25R95_DEBUG to have some extra traces

    Rgds

    BT

    1 reply

    B
    Brian TIDALAnswer
    Technical Moderator
    March 24, 2022

    HI,

    the SSI_0 (signal D9 on CN5 connector of the X-NUCLEO-NFC03A1 board) has to be set to low (see table 4 of the CR95HF datasheet) in order to properly select the UART interface during the startup sequence (see § 3.2 of the datasheet). Make sure the GPIO connected to SSI_0 is set to low in your configuration.

    On Software side, the UART interrupt has to be enabled and the HAL_UART_TxCpltCallback, HAL_UART_RxCpltCallback and HAL_UART_ErrorCallback have to be populated with  st25r95UartTxCpltCallback (resp. st25r95UartRxCpltCallback, st25r95UartErrorCallback). See https://community.st.com/s/question/0D50X0000B7YwL7SQK/how-to-use-uart-interface-instead-of-spi-with-xnucleonfc03a1-and-xcubenfc3-polling-demo for further details (it also provides a demo package based on X-CUBE-NFC3 2.0.0 that should help).

    st25r95Initialize() does 5 attempts to send an echo command with UART TX/RX in blocking mode. If the UART communication fails (no reply to echo command), the st25r95Initialize returns ERR_SYSTEM. If it returns ERR_NONE, it means your UART communication is OK. Then further communication uses UART TX/RX with interrupt mode. If this part is failing, make sure to enable the UART interrupt and to populate the callbacks.

    Note: You can enable ST25R95_DEBUG to have some extra traces

    Rgds

    BT

    L
    LM.2Author
    Visitor II
    March 25, 2022

    Thank you Brian

    I didn't realise that it was swapping from polling to interrupt mode. Adding the interrupt callbacks fixed all of my issues.

    Terms & ConditionsAccessibility statement