Mesa 7C80, RPi4, 20cm ribbon cable and SPI speeds

Hi,

using the prepared OS image "rpi-4-debian-bookworm-6.12.11-arm64-ext4-2025-01-27-0404.img.xz" from linuxcnc.org on a Pi4/4GB, I have no luck talking to my 7c80 board, which is connected with a 20cm ribbon cable to my RPi:

$ mesaflash --spi --device 7c80 --addr /dev/spidev0.0 --readhmid
Unexpected cookie at 0100..0110:
00000000 00000000 00000000
No 7C80 board found

This is both for the system-wide installed mesaflash as well as a separate build straight from github sources as of today.

I am (now) aware that cable length might be an issue here as SPI runs at a swift 20 MHz.

If possible (as replacing the cable with a much shorter one would involve quite a bit of mechanical disassembly and rework of my controller box) I would like to try the SPI connection first at slower speeds.

Is it possible to test (maybe bitbang even?) the SPI connection to the 7C80 FPGA to test whether the whole setup is working in principle? If so, are there any major problems expected then running everything with a reduced data rate (I am only planning to drive two steppers with this setup, so hopefully not a lot of bandwidth is needed)?

Can the FPGA be accessed slowly or are there timeouts preventing this?

I brazenly tried to reduce the SPI speed in spi_boards.c down to various rates, down to 100kHz, but that didn't help.

All zeros data is possibly a connection or firmware issue.

I would try a short cable though

Note that a 20 CM cable is very likely to be unreliable due to signal
integrity issues (both ringing and ground bumping) The 7C80
and 7C81 are designed for the RPI to mount on top of the card with a
~40 mm cable

Hey PCW,

thanks for the quick reply. Ok, I'll plan on a shorter cable.

However, just to test things out, wouldn't slowing SPI (and if necessary by a lot) help with any ringing and similar transient issues? Or am I missing something? I can only imagine strong crosstalk that would actually causes glitches between SCK and MOSI/MISO to be an issue at slow speeds - and that is surely not expected @ 20cm as it would still be way too short for that?

If you agree, would reducing the rate as I did in spi_boards.c (max in spi_boards_init) work or are there other things that would prevent such an approach?

Unfortunately, lowering the clock rate does not improve SI issues with the SPI clock itself.
The firmware uses an actual clock pin rather than an oversampled input so any ringing
will be an issue. Its possible to make firmware suited to longer cables but at the expense of
SPI clock rate.

 

Okay understood. So you imagine something  like SCK ringing in the 20cm cable triggering your SPI logic twice? Fair enough, I'll try adding a .1n or so cap to the SCK line then, maybe that will help.

And .. yes .. as feedback on your(?) product I think it would be nice if there would be an option to have slower SPI with sampling. I have a 7i96 in use since quite a while on a 3-axis router and am quite happy with it, it works well. However, having to use USB ethernet on the other Pi I am using for that (for regular networking) is a bit of an annoyance / issue. This is why I went with the 7C80 now.

I don't know how my setup actually works, I have a temporary connection between the RPi5 and my clone via some very messy 150mm DuPont cables, for some reason I can't work out I've seen no comm issues in testing.
Unfortunately not having access to a CRO means I can't actually see the signal.