2024-04-19 03:56 AM
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
Solved! Go to Solution.
2024-04-22 01:30 PM - edited 2024-04-22 01:40 PM
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
2024-04-19 06:26 AM
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
2024-04-19 08:07 PM
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
2024-04-22 01:29 AM
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
2024-04-22 12:12 PM
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...
2024-04-22 01:30 PM - edited 2024-04-22 01:40 PM
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