2019-09-13 08:45 AM
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 ?
Solved! Go to Solution.
2019-09-17 06:26 AM
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
2019-09-14 03:56 PM
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:
Thanks
Rgds
BT
2019-09-16 04:00 AM
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 :
Echo Command:
Wait for status to change :
Read response (get 0x0e and not 0x55)
Overall summary :
2019-09-16 05:14 AM
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:
This should solve you issue as you are reading the first MISO byte whereas it is should be the next one.
Rgds
BT
2019-09-17 06:26 AM
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
2024-05-16 12:51 AM - edited 2024-05-16 01:58 AM
"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?
2024-05-30 02:40 AM
Hi @Shreyas771
I would suggest to create a new post for your question rather than using an already answered topic.
Thanks
Rgds
BT