cancel
Showing results for 
Search instead for 
Did you mean: 

CR95HF echo command retuens 0x0E

Philip Lane
Associate II

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

😎 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 ?

1 ACCEPTED SOLUTION

Accepted Solutions
Philip Lane
Associate II

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

View solution in original post

4 REPLIES 4
Brian TIDAL
ST Employee

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

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

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

Brian TIDAL
ST Employee

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

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
Philip Lane
Associate II

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