Waveshare 2-ch can FD hat setup in VeCan and RpiGpioSetup appears to work, but can9 interface is not created

[midnightblock24]

I ran./VeCanSetup/setup to install the WaveShare 2-CH can FD hat... worked great. It said to run RpiGpioSetup to clean up the pin conflicts, which I did, then ran VeCanSetup/setup again, peerrfect.

I connected my SOK BMS on can8, and configured it... all is beautiful.

However

can9 never showed up in the gui.

so, I go back to CLI and look to see what interfaces exist:

#ip link

...and nada on the can9. can8 exists and is UP, but no can9:

5: can8: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 100
link/can

Where do I edit the config to specify can9?

[kwindrem]

It is really hard to say what needs to change. My guess is you still have GPIO conflicts if you aren't seeing anything in dmesg or iplink about the second can port. Simply running RpiGpioSetup won't necessarily clear up conflicts. It does offer a second set of GPIO assignments for relay outputs and digital inputs that MAY eliminate conflicts. It depends on the hat module(s) being used.

I've also seen Waveshare change GPIO assignments so look at the documentation for your specific module.

VeCanSetup does offer setting up one or both ports of a dual port hat but I'm guessing you did that.

[midnightblock24]

Findings / tl;dr

• SPI1 is not instantiated because of a conflict on gpio19 / pin 35
• I believe this keeps can1 / can9 from being configured since there is no spi1 available
• I guess maybe its the weird or non-conventional pin mapping of the Waveshare itself?

Notes to Self / Long

• Who ever used awk, sed and grep in the same line? That's a flex...
• Where is file descriptor 9 exec'd?
• "config.txt" is /u-boot/config.txt
• Config looks correct:

#### begin CAN overlay
# Waveshare 2-channel Isolated CANbus FD Hat
# instantiates as can0 and can1 ONLY !!!
# use udev rules to rename
[all]
dtoverlay=spi1-1cs
dtoverlay=mcp251xfd,spi0-0,interrupt=25
dtoverlay=mcp251xfd,spi1-0,interrupt=24
#### end CAN overlay

• I assume interrupt # is the BCM# / gpio#? No conflicts on 24 or 25 in dmesg
• spi1.0 never shows up in dmesg...
• ...but... the auxiliary spi is denied the gpio (19) that is seeks. Is auxiliary spi the same as spi1.0? Probably...

[    5.089074] pinctrl-bcm2835 3f200000.gpio: pin gpio19 already requested by 3f200000.gpio; cannot claim for 3f215080.spi
[    5.099972] pinctrl-bcm2835 3f200000.gpio: error -EINVAL: pin-19 (3f215080.spi)
[    5.107401] pinctrl-bcm2835 3f200000.gpio: error -EINVAL: could not request pin 19 (gpio19) from group gpio19 on device pinctrl-bcm2835
[    5.119650] spi-bcm2835aux 3f215080.spi: error -EINVAL: Error applying setting, reverse things back

• I don't see any ref to GPIO 24, 25 or 19 in the /etc/venus/gpio_list file...

# Relay 1   GPIO 2 / header pin 3 ALTERNATE assignment
2  out relay_1
# Relay 2   GPIO 17 / header pin 11
17  out relay_2

# Relay 3   GPIO 27 / header pin 13
27  out relay_3
# Relay 4   GPIO 22 / header pin 15
22  out relay_4
# Relay 5   GPIO 12 / header pin 32 ALTERNATE assignment
12  out relay_5
# Relay 6   GPIO 4 / header pin 7 ALTERNATE assignment
4  out relay_6

# these have pull UPs
# Digital input 1   GPIO 5 / header pin 29
5   in digital_input_1
# Digital input 2   GPIO 6 / header pin 31
6   in digital_input_2

# in stock code these have pull DOWNs
#### modified to pull UPs by the GPIO overlay that is installed as part of this package

# Digital input 3   GPIO 13 / header pin 33
13  in digital_input_3
# Digital input 4   GPIO 3 / header pin 5 ALTERNATE assignment
3  in digital_input_4
# Digital input 5   GPIO 26 / header pin 37
26  in digital_input_5

#### Gracefull shutdown input
#### Note this input is NOT added to the available I/O used by Venus OS !!!!
# GPIO 16 / header pin 36
16  in digital_input_6

• Ridiculously helpful link: interactive rpi pinout, and these as well: rpi 2 and 3 side by side and rpi2,3,4 all in one
• gpioinfo shows that (as it is somehow broken) interrupt 24 is unused, but, unexpectedly 19 is also unused despite being claimed by 3f200000.gpio... if it was claimed, why is it not being used? ...and, there is no SPI1 (16, 17, 18, 19, 20, 21) at all. Shouldn't 16, 17, 18 be SPI1 CE.? Anyway, 16 and 17 are mapped with /etc/venus/gpio_list, but not at variance with default.

gpiochip0 - 54 lines:
	line   0:      unnamed       unused   input  active-high 
	line   1:      unnamed       unused   input  active-high 
	line   2:      unnamed      "sysfs"  output  active-high [used]
	line   3:      unnamed      "sysfs"   input  active-high [used]
	line   4:      unnamed      "sysfs"  output  active-high [used]
	line   5:      unnamed      "sysfs"   input  active-high [used]
	line   6:      unnamed      "sysfs"   input  active-high [used]
	line   7:      unnamed   "spi0 CS1"  output   active-low [used]
	line   8:      unnamed   "spi0 CS0"  output   active-low [used]
	line   9:      unnamed       unused   input  active-high 
	line  10:      unnamed       unused   input  active-high 
	line  11:      unnamed       unused   input  active-high 
	line  12:      unnamed      "sysfs"  output  active-high [used]
	line  13:      unnamed      "sysfs"   input  active-high [used]
	line  14:      unnamed       unused   input  active-high 
	line  15:      unnamed       unused   input  active-high 
	line  16:      unnamed      "sysfs"   input  active-high [used]
	line  17:      unnamed      "sysfs"  output  active-high [used]
	line  18:      unnamed       unused   input  active-high 
	line  19:      unnamed       unused   input  active-high 
	line  20:      unnamed       unused   input  active-high 
	line  21:      unnamed       unused   input  active-high 
	line  22:      unnamed      "sysfs"  output  active-high [used]
	line  23:      unnamed       unused   input  active-high 
	line  24:      unnamed       unused   input  active-high 
	line  25:      unnamed  "interrupt"   input  active-high [used]
	line  26:      unnamed      "sysfs"   input  active-high [used]
	line  27:      unnamed      "sysfs"  output  active-high [used]
	line  28:      unnamed       unused   input  active-high 
	line  29:      unnamed       "led0"  output  active-high [used]
	line  30:      unnamed       unused   input  active-high 
	line  31:      unnamed       unused   input  active-high 
	line  32:      unnamed       unused   input  active-high 

[midnightblock24]

Answer For the interested

It appears that I had run #/data/RpiGpioSetup/setup before I had configured the Waveshare CANHatFD via #/data/VeCanSetup/setup

This caused the VenusGpioOverlay.dtbo to be loaded in /u-boot/config.txt instead of the correct VenusGpioOverlayForCanHats.dtbo

Simply uninstalling RpiGpioSetup and re-installing it fixed the issue.

Thanks @kwindrem for all your great contributions!