Advanced Search

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.

 

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?

What does

ip a

report?

I have seen a similar issue when the network GUI used was wicd
which breaks Ethernet connections when setting up a WLAN
(network manager works, wicd is broken or was broken)

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

Works for me
www.youtube.com/shorts/ZcQjW4829R0

the modbus has some delay, thats why it is a little asynchronous


@Andrew
there is also a template now for your board, but without input yet, would be nice if you can give me your config for the inputs

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.

scotta wrote:

1. Convert an ST-Link to a CMSIS-DAP probe by using a a second ST-Link and the ST-Link utility to flash the CMSIS-DAP firmware.

mvdlande.wordpress.com/2015/10/05/cmsis-...ink-v2-mini-adapter/

2. Use pyOCD with the newly flashed CMSIS-DAP probe to flash the firmware to the controller board

python -m pip install -U pyocd
pyocd flash .\remora-rt1052-3.1.3.bin --target mimxrt1050_quadspi

github.com/scottalford75/Remora-RT1052-c...ora-rt1052-3.1.3.bin
Hello, I'm coming back to the charge on my RT 1052 card, I'm trying to flash with the CMSIS-DAP firmware but I have an error message the card is not detected?

 

 

Today i reran the PnCConf and the Startup Error didn't show.
But the WLAN Problem still persists.

I am running Debian on my Thinkpad T420
The mesa is connected to the Ethernet port and when I connect to WLAN the connection to the MESA Card fails, it happens both with 10.10.10.10 and with 192.168.1.121.

Network:
IP 192.169.1.10 Mask: 255.0.0.0 Gate: 0.0.0.0
IP 10.10.10.11 Mask: 255.0.0.0 Gate: 0.0.0.0

Yes, I had the Ohmic sensing into the B encoder input on TB2.

That's OK with 7i96dpl.bit firmware (that has three separate encoder 'A' pins)

Change quotes around D3 (note the different appearance when you try to open the attached XML):

 

Could you post your hal files (IE the one that uses caxis.comp and the one with the orient.comp)?

I made a new xml with only the beckhoff EK1100. Now i get a new error

Another way to fix that is to chose the output polarity of the PWM
so its 0V at startup or watchdog bite (the STEP- pin) and then invert
the PWM in the hal file.

Its still a good idea to disable the spindle when LinuxCNC is not running
If the enable is an optocoupler input, a single resistor (R1)  will do
If its a 5V logic input, you need R2.

Safest would be to implement both (0 PWM at startup which is just a
wiring and hal change) and drive enable.