LinuxCNC with RIO (FPGA) SPI Issue: Unexpected 'HXHP' Response

Current Situation and Probrem
I am trying to establish stable SPI communication between a Raspberry Pi 4 and an ICE40UP5K FPGA (IceShield) using LinuxCNC and the RIO framework.
While basic SPI communication seems functional outside of LinuxCNC, I am currently encountering unexpected behavior during runtime: the system consistently logs "WRONG DATA" with "HXHP" as the received header.
My goal is to understand what SPI response LinuxCNC expects from the FPGA, and how to configure both ends to ensure correct communication.

Environment

•     Raspberry Pi 4
•     LinuxCNC version: 2.9.4 (same behavior also observed in 2.9.3 and 2.8.4)
•     OS: Official LinuxCNC 2.9.4 Raspberry Pi 4 Bookworm image
•     FPGA: ICE40UP5K-SG48I (IceShield)
•     Clock source: Since gpio is not available on Bookworm, I use pigpiod to generate a 5 MHz clock on GPIO 4:
       

  #!/bin/bash sudo pigpiod pigs hc 4 5000000

    I also modified spiflash.sh to work with pigpiod under Bookworm

FPGA Status

• The Verilog design (rio.v) is written to return the SPI response header "data" (0x64617461)
• The FPGA’s LED is blinking and SPI data is returned via external tools. This suggests the FPGA is operating correctly with the supplied clock.

SPI Test Using Python
To confirm basic SPI functionality outside of LinuxCNC, I used this script:This consistently returns "data" from the FPGA, suggesting that low-level SPI transport is functioning properly.

Behavior in LinuxCNC

• In the rio_readwrite() function, logging shows the SPI response always begins with "0:02" (0x30 0x3A 0x30 0x32)
• However, the LinuxCNC log reports "WRONG DATA" with the string "HXHP" (0x48 0x58 0x48 0x50)
• I did not find any logic in the Verilog code that would return "HXHP"
• I suspect that "HXHP" is generated internally by LinuxCNC when an unrecognized or malformed header is received

Observations

• SPI communication appears to be working, and the FPGA is returning a response
• However, there may be a mismatch between the header format LinuxCNC expects and what the FPGA sends
• LinuxCNC may be replacing the unrecognized header with "HXHP" as a default or fallback

Questions

• Where in the LinuxCNC source is "HXHP" generated or substituted? Is this a fallback response?
• Is the "0:02" sequence a standard header sent by LinuxCNC under the RIO configuration?
• What header or message structure (e.g. MSGID) is LinuxCNC expecting from the FPGA?
• Are there documented or example SPI response formats compatible with riocomp?

I would appreciate any advice or clarification.
I can provide Verilog and riocomp.c sources if helpful. Thank you.















 

you need a clock of min. 10Mhz for the ICE4018Mhz clock, not 5Mhz, don't know why


than you need to set the osc value to your new clock speed in
riocore/boards/IceShield/board.json

you can test the spi connection with the rio-test tool:i think to have the gpio commands you need to install WiringPi:
github.com/WiringPi/WiringPi/releases/tag/3.0

sorry, can not test it at the moment

Switching from `pigpiod` to WiringPi resolved the issue—SPI communication is now working as expected.
Thank you very much for the detailed explanation.

I followed your instructions and used the following `gpio` commands to generate the clock:

gpio mode 7 clock
gpio clock 7 5000000

While I couldn’t measure the actual frequency, the FPGA responded properly after applying this change, so it seems that the commands produced an 18 MHz clock as you suggested.
My `board.json` already contained the following settings:

"clock": {
"osc": "18000000",
"speed": "29812000",
"pin": "35"
}

After this setup, the `rio-test` tool returned valid results, and LinuxCNC no longer shows the `"HXHP"` error.

It appears that the 5 MHz clock generated by `pigpiod` was not suitable for the ICE40, and this prevented the FPGA from functioning correctly.

Thanks again—this completely solved the problem.