NFC03A1 rfalNfcInitialize return 36

[venukrish]

we are observing weird error during initilization...

enclosed the log dump (board2_init_fail_log.txt and ll13_01_board2_success_logs.txt)

on Raspberry pi with 2 NFC03A1 boards (SPI3.0 works well, SPI0.0 fails)

2 independent binaries are being used with the respective SPI and control gpios.

The same board some time works(log enclosed - ll13_01_board2_success_logs.txt) but most of the time we observe Error 36 (ERR_HW_MISMATCH)

Observations

1. st25r95CheckChipID() fails

2. ran this in a loop for 5 times and observed from 2 or 3 iteration, the chip responds with some data

3. st25r95Initialize() returns ERR_NONE (st25r95CommandEcho() is ok 0x55 being received)

4. st25r95SPIPollRead() returns 0 (indicating IRQ_OUT is going low.)

Pls advise

[Brian TIDAL]

Hi

in the success log, I can see gpio_clear - /sys/class/gpio/gpio14 and gpio_set - /sys/class/gpio/gpio14 that correspond to SPI Select (CS low) and SPI Deselect (CS Hi) for each frame. I not see such SPI Select / SPI Deselect in the fail log. make sure to have a dedicated SPI Chip Select signal (CS) for each X-NUCLEO-NFC03A1. Can you describe how the 2 X-NUCLEO-NFC03A1 boards are connected to the Raspberry Pi board? There must be a dedicated signal on each board for  SPI Chip Select, IRQ_IN and IRQ_OUT. 

Also, can you connect a logic analyzer on SPI (CLK, MOSI, MISO, CS) + IRQ_IN + IRQ_OUT on each board and provide the combined trace of those signals ?

My feeling is that the IRQ_OUT GPIO is wrongly connected/configured.

 

Rgds

BT

[venukrish]

1. Yes, separate sets of pins are allocated for SPI Chip Select, IRQ_IN and IRQ_OUT for each board.

2. Yes i have removed the gpio set /clear prints. i will include the same and re run

3. will check IRQ_OUT pin, can you clarify what you mean by wrongly configured ?...if its not connected/wrongly connected st25r95SPIPollRead() will NOT return 0 right ?

4. i donot have logic analyser setup

[Brian TIDAL]

Hi

---

@venukrish wrote:

3. will check IRQ_OUT pin, can you clarify what you mean by wrongly configured ?...if its not connected/wrongly connected st25r95SPIPollRead() will NOT return 0 right ?

---

My feeling is that the IRQ_OUT pin of the second reader is always seen as low. This can be due to a wrong configuration the the GPIO or IRQ_OUT being connected to the wrong pin, etc.

Rgds

BT

 

[venukrish]

re run with gpio set/clear prints. .. same results. enclosed the logs

checked the connection and also gpio pu state. seems to be correct...i manully pulled up the pin state...

somehow i have a doubt about the timing response of the chip.. some times on 4th or 5th retry i observe some data received from the chip..

kindly suggest...

[Brian TIDAL]

Hi,

I had a look to your new trace. After sending the IDN command (01h 00h), the first byte returned to the SPI read control is 06h. Bit #3 is 0 which means data cannot be read from the ST25R95 (see table 5 in the Datasheet).  See traces with comment:

 

gpio_set - /sys/class/gpio/gpio14
st25r95Initialize: exhausted attempts 5 returning 0
gpio_clear - /sys/class/gpio/gpio14
Tx: 0x0 
Rx: 0x6 
Tx: 0x1 
Rx: 0x6 
Tx: 0x0 
Rx: 0x6 
gpio_set - /sys/class/gpio/gpio14
>>>> 0100 <<----IDN command
st25r95SPIPollRead: ret=0
gpio_clear - /sys/class/gpio/gpio14
Tx: 0x2 
Rx: 0x6 <<----Value 06h here means no response data available yet
Tx: 0x0 
Rx: 0x0 
Tx: 0x0 
Rx: 0x0 
gpio_set - /sys/class/gpio/gpio14
<<<< 0000

 

 This means that "st25r95SPIPollRead: ret=0" is not true and you try to read whereas nothing is yet in the ST25R95 internal buffer. So the GPIO connected to the IRQ_OUT does not provide the proper value. 

For your information, the first command being sent is a IDN (identification) command. When receiving this command the ST25R95 computes the CRC of the ROM and then returns the revision number plus some additional information. It takes approximately 6 ms to calculate the CRC for the entire ROM. If the IRQ_OUT is not properly managed on MCU side, the MCU will try to read the response whereas the response is not yet available. This is what I see in your trace. 

In order to debug your issue, read and print the gpio value before sending a command and then just after. If the gpio is always low, this means there is an issue. Also, timestamps should be added in the trace.

Rgds

BT