Skip to main content
Visitor II
September 13, 2019
Solved

CR95HF echo command retuens 0x0E

  • September 13, 2019
  • 5 replies
  • 1941 views

I am attempting to connect to one of ST's CR95HF NFC chips, but I can't get it to respond correctly to the echo command.

1) Reset CR95HF by toggling the IRQ line

2) Set chip select line low

3) Send two bytes : 0x00 0x55 = Command Echo

4) Set chip select line high

5) Set chip select line low

6) Send one byte : 0x03 to request response, waiting for bit 3 to be high

7) Set chip select line high

8) When bit 3 is high, set chip select line low and send one byte : 0x02 = Read data

9) Instead of the expected 0x55, I Receive 0x0E

I have checked all the timing diagrams, all timings appear to be ok.

I have checked the signals on a scope and digital analyser, all are ok.

Any suggestions ?

    This topic has been closed for replies.
    Best answer by Philip Lane

    Hi,

    Thanks - all working now.

    It was due to the Tx and Rx lengths, they both need to be 2 for sending the echo and also for reading the responce. Plus the responce packet is two bytes long, not one. I's 0x0E 0x55 !

    Thanks for your help

    5 replies

    Technical Moderator
    September 14, 2019

    Hi,

    Some tips or comment:

    As per the ST25R95/CR95HF datasheet, toggling the IRQ_IN pin does not reset the device. See § §3.1 and 3.2 in the ST25R95 datasheet for usage of the IRQ_IN.

    Before sending an echo command, you have to wait for t3 delay (oscillator setup): see § 3.2 startup sequence

    I would recommend to poll the IRQ_OUT pin status rather than using the 0x03 poll control (see Caution note in §5.9). Our driver code implementation is based on IRQ_OUT. See X-CUBE-NFC3 package for FW support of the ST25R95/CR95HF.

    See https://community.st.com/s/question/0D50X0000AAIdlFSQT/cr95hf-error-0x71-spi-interface for an example of startup sequence. This sequence is implemented in our X-CUBE-NFC3 FW package.

    Feel free to share more details regarding your implementation of the CR95HF such as:

    • board being used (e.g. X-NUCLEO-NFC03A1)
    • MCU being used (e.g. STM32 on nucleo board)
    • reasons to not use the X-CUBE-NFC3 FW package.

    Thanks

    Rgds

    BT

    Visitor II
    September 16, 2019

    Hi,

    Thanks. I toggle the IRQ_IN pin to wake up the chip and then send a reset command (0x01) to reset it.

    At the moment I can' use the IRQ_OUT, I dont have any spare pins. Is it really necessary to use this pin or is the polling ok ?

    I am using an ESP32 to communicate woth the CR95HF - so I can't really use the X-CUBE package.

    I have attached some screen grabs to show thw signals and theit timings.

    When sending an echo command, :

    1) is it two bytes ? 0x00 and 0x55, or just 0x55 ?

    2) Is the length parameter 1 ?

    3) is the rxlength parameter 1 ?

    Thanks

    Phil.

    Reset command :

    0690X00000ARErZQAX.png

    Echo Command:0690X00000ARErAQAX.png

    Wait for status to change :

    0690X00000AREroQAH.png

    Read response (get 0x0e and not 0x55)

    0690X00000AREs3QAH.png

    Overall summary :

    0690X00000AREsDQAX.png

    Technical Moderator
    September 16, 2019

    Hi,

    for your information, the X-CUBE-NFC3 v2.0.0 contains our portable NFC stack (called RFAL) and our ST25R95/CR95HF portable driver. This can be ported to non ST platform with minimum effort (a platform.h files is used to map SPI communication, timers and traces on the proper calls for a given platform). I would recommend to use the X-CUBE-NFC3 in order to reduce the porting effort.

    Back to your question:

    • Is it really necessary to use IRQ_OUT pin or is the polling ok ? If you do not plan to use the Idle command, then you can use the 0x03 poll control
    • When sending an echo command, : is it two bytes ? 0x00 and 0x55, or just 0x55 ? The 0x00 control byte (Send) has to sent prior to any command
    • When sending an echo command, Is the length parameter 1 ? The echo command is an exception and does not have a Len parameter. Therefore, the following byte has to be sent for a complete echo command: 0x00 (Send Control byte) 0x55 (echo command)
    • When sending an echo command, is the rxlength parameter 1 ? What do you mean by rxLengh parameter? See figure 8 in the ST25R95 datasheet for the explanation about reading from the device:
      • send 0x02 control byte (Read), the MISO can be dropped, the data will start a t the next MOSI byte
      • send dummy bytes and read the MISO

    This should solve you issue as you are reading the first MISO byte whereas it is should be the next one.

    Rgds

    BT

    Philip LaneAuthorAnswer
    Visitor II
    September 17, 2019

    Hi,

    Thanks - all working now.

    It was due to the Tx and Rx lengths, they both need to be 2 for sending the echo and also for reading the responce. Plus the responce packet is two bytes long, not one. I's 0x0E 0x55 !

    Thanks for your help

    Visitor II
    May 16, 2024

    "When bit 3 is high, set chip select line low and send one byte : 0x02 = Read data"

    Which bit 3 should I check to know the status of the module?

    Technical Moderator
    May 30, 2024

    Hi @Shreyas771 

    I would suggest to create a new post for your question rather than using an already answered topic.

    Thanks

    Rgds

    BT