UNSOLVED Installing DSF on a Banana-Pi-M3 with Raspbian OS

Falcounet

I'm trying to do the same thing but using an OrangePi4B SBC (RK3399 SoC)

On this SBC, the pin 22 of the GPIO header is mapped to GPIO0_B5.
This SoC has 5 GPIO controllers.
Each controller controls 32 lines and each line is 32 bits.
So, in order to find the GPIO number of port GPIO0_B5, I have to use this formula : 0 * 32 + 1 * 8 + 5 = 56 (A=0, B=1, C=2, D=3, E=4).
Pin 22 (GPIO0_B5) is GPIO number 56.
GPIO number 56 is also the line 26 of the 2nd GPIO controller /dev/gpiochip1.

I tried to connect a wire from pin 1 (3.3V) to pin 22 and use gpioget gpiochip1 26. I got 0 while not connected and 1 while connected so that's ok.

I also had to change the SPI device because SPI bus 1 is exposed on pins 19, 21, 23 and 24.
Also needed to decrease SpiBufferSize.

I modified /opt/dsf/conf/config.jsonas follows:

"SpiDevice": "/dev/spidev1.0",
"SpiBufferSize": 4096,
"SpiTransferMode": 0,
"SpiFrequency": 8000000,
"SpiConnectTimeout": 500,
"SpiTransferTimeout": 500,
"SpiConnectionTimeout": 4000,
"MaxSpiRetries": 3,
"SpiPollDelay": 25,
"GpioChipDevice": "/dev/gpiochip1",
"TransferReadyPin": 26,

But I still have no luck with communication.
After systemctl restart duetcontrolserver.service, I get the following error in journalctl -xe:

Jan 28 21:45:23 orangepi4 DuetControlServer[2311]: [fatal] Could not connect to Duet (Timeout while waiting for transfer ready pin)
Jan 28 21:45:23 orangepi4 DuetControlServer[2311]: [debug] System.OperationCanceledException: Timeout while waiting for transfer ready pin
Jan 28 21:45:23 orangepi4 DuetControlServer[2311]:    at DuetControlServer.SPI.DataTransfer.WaitForTransfer(Boolean inTransfer) in /home/christian/Duet3D/DuetSoftwareFramework/src/DuetCo
Jan 28 21:45:23 orangepi4 DuetControlServer[2311]:    at DuetControlServer.SPI.DataTransfer.ExchangeHeader() in /home/christian/Duet3D/DuetSoftwareFramework/src/DuetControlServer/SPI/Dat
Jan 28 21:45:23 orangepi4 DuetControlServer[2311]:    at DuetControlServer.SPI.DataTransfer.PerformFullTransfer(Boolean connecting) in /home/christian/Duet3D/DuetSoftwareFramework/src/Du
Jan 28 21:45:23 orangepi4 DuetControlServer[2311]:    at DuetControlServer.SPI.DataTransfer.Init() in /home/christian/Duet3D/DuetSoftwareFramework/src/DuetControlServer/SPI/DataTransfer.
Jan 28 21:45:23 orangepi4 DuetControlServer[2311]:    at DuetControlServer.Program.Main(String[] args) in /home/christian/Duet3D/DuetSoftwareFramework/src/DuetControlServer/Program.cs:li
Jan 28 21:45:23 orangepi4 systemd[1]: duetcontrolserver.service: Failed with result 'protocol'.
Jan 28 21:45:23 orangepi4 systemd[1]: Failed to start Duet Control Server.

Not sure what I miss here.

EDIT:
I also tried "TransferReadyPin": 56, just in case ...
But I get the following error :

Jan 28 22:07:48 orangepi4 DuetControlServer[2403]: [fatal] Could not connect to Duet (Error 22. Cannot put line into event mode.)

So I think the TransferReadyPin configuration is correct.

chrishamm

Please check out my last post, you must use the gpioinfo utility to find the right GPIO device + number. Decreasing the SPI buffer size is a really bad idea because that requires a custom RRF build, without that the communication may fail unexpectedly whenever large chunks of data are transferred. See here for the right way to configure the SPI buffer size under Linux.

PS: If the line cannot be put into event mode, it's probably already allocated by something else (e.g. the sysfs driver) and gpioinfo will report it as [used]. In that case you must free it before DCS can use it.

Falcounet

@chrishamm I don't understand how gpioinfo could help me.
I decreased the SPI buffer size because I had a warning about it but I will check later how to increase that.

Also, I think the line cannot be put in event mode because 56 is an invalid number for gpiochip1. It's only 0 to 31 because it only have 32 lines.

chrishamm

@Falcounet gpioinfo lists the available pins for each gpiochip device and the corresponding pin indices as required by DCS and it reports if the corresponding pins are available or blocked (i.e. used). The warning about the SPI buffer size in DCS is there for the same reason I already explained - leaving the default value can lead to unstable SPI connections. The buffer size property in the DCS config is only intended for third-party firmware forks and it should not be modified by Duet users.

Falcounet

@chrishamm Well, I'm unable to post the gpioinfo output here (content flagged as spam) but you can see it here

and as I said in my previous post, I saw pin 22 is mapped to gpiochip1 , line 26

chrishamm

@Falcounet That looks fine, then I recommend changing the bufsiz module parameter of the spidev module to 8192 as described before and to reset the buffer size in config.json to 8192. Do you get the same error about the transfer ready pin when you start DCS as root (via /opt/dsf/bin/DuetControlServer)? If not, check the permission for gpiochip1. You may have to add the dsf user to the group that owns that node.

Falcounet

@chrishamm Same error when starting as root :

root@orangepi4:~# /opt/dsf/bin/DuetControlServer
Duet Control Server v3.2.0
Written by Christian Hammacher for Duet3D
Licensed under the terms of the GNU Public License Version 3

[info] Settings loaded
[info] Environment initialized
[fatal] Could not connect to Duet (Timeout while waiting for transfer ready pin)

But anyway, I already checked the permissions should be ok for user dsf.
I also increased the SPI buffer, thanks for the modprobe hint !

NB: It works when using a raspberry pi (so its ok on the board and cable side).

I think I will use a logic analyzer to check if SPI works well.

chrishamm

@Falcounet DCS expects the transfer ready pin to be high when it is started and it's toggled before every following SPI transfer. Perhaps it's worth to check that particular pin first via gpioget once the Duet is powered up and connected. And make sure there is no SD card in the Duet when you start DCS.

Falcounet

@chrishamm I'm using the LPC/STM32 fork of RRF on a SKR Pro board.
gpioget gpiochip1 26 returns 0 when I power up the board.

As you said, it should be 1. I will have a closer look again at the wiring.

Falcounet

Well, I was mixing pins and GPIO numbers ...

PIN 22 on the GPIO header is related to gpiochip1 line 24 and not 26 !

gpioget gpiochip1 24 returns 1 with the board connected

Now I have another error:
Jan 29 14:22:01 orangepi4 DuetControlServer[2188]: [fatal] Could not connect to Duet (Board is not available (no header))

Falcounet

Update : it works with the SPI buffer sets to 4096 but I'm getting no header errors with the buffer set to 8192.
(Nothing changed on this side on the LPC/STM32 port)

There is probably some problem with the SPI driver. I'm going to check this.

Falcounet

Well, I don't know what happened with the SPI buffer, maybe some problem with the driver but it worked after resetting it to 8192.

I did all the steps again from scratch to be sure and it works now.

By the way, a documentation is written and may help anyone who want to use DSF on another SBC than a RaspberryPi : https://teamgloomy.github.io/dsf_on_armbian.html

Feel free to share the settings which work on your board to complete the "Known boards settings" section.