Experimental "USB to CANbus bridge" mode

Thanks Jake,

I was overlooking it indeed. dmesg showed CAN bus but I was assuming it is my CAN hat. I was able to bring the interface up and canbus_query.py shows the mainboard MCU. Now time to find the bag of RJ11’s…

BTW - does the Octopus have a terminator on the bus? I couldn’t find anything in the documentation about termination resistor.

I don’t fully understand the schematic, but yes it does have a termination resistor. When connected to my bus which has a 120ohm resistor at the end I show 60ohms between L and H.

Thanks! There seems to be indeed terminator installed.

All good now - CAN bridge firmware works for me so far too. Octopus Pro 446 chip.

To provide some feedback - setup works well and unless firmware restarts are needed, seems stable. Got few hours printing on my printer with the bridge firmware now, all completed with no issues.

Restarting firmware causes often a situation where either of the mcu’s (mainboard or toolboard) enters a state that is no longer communicating via the CAN bus even after reinstating it in linux, until power cycling/resetting it (more often happens with the toolboard).

The “FIRMWARE RESTART” issue gets sorted out to a large extent by changing can0 interface mode in /etc/network/interfaces.d/can0 from auto to allow-hotplug. That takes care of bringing up can0 upon reset in a timely matter. MCU’s would usually not re-connect until consecutive RESTART is issued few seconds later, but the situation is MUCH improved now. I wonder if there is way to introduce some waits in FIRMWARE RESTART to accommodate for that timing.

2 Likes

You need to put jumper into BOOT0, RESET, remove jumper and you will be able to flash.

This code has been merged into the main Klipper branch ( Support for “USB to canbus bridge" mode by KevinOConnor · Pull Request #5583 · Klipper3d/klipper · GitHub ).

-Kevin

4 Likes

You can try this proof of concept to flash over USB when in USBCAN mode: Draft: flash_usb: allow to flash via usb-to-can-bridge by ayufan · Pull Request #5608 · Klipper3d/klipper · GitHub.

It uses RJ12, not 11.
RJ11 will not work

-Kharma

The schematic and wikipedia disagree:

RJ11 uses a 6-pin modular housing with the 2 center pins wired, which is what the Octopus 1.1 has. RJ12 is the same housing, but with more pins wired.

This is not correct. CAN only needs the middle two pins. RJ11 has 4 around the middle, RJ12 has all 6 pins. Both will work just fine.

I’m currently using RJ11 and can confirm it works fine

That did it; thank you.

After flashing, my Octopus board doesn’t work without a reset; it just doesn’t appear on the USB bus. I see the following in the systemd journal:

Jul 02 13:40:29 vcore3 sudo[2272]:     root : TTY=pts/2 ; PWD=/home/pi/klipper ; USER=root ; COMMAND=/usr/bin/dfu-util -d ,0483:df11 -R -a 0 -s 0x8008000:leave -D out/klipper.bin
Jul 02 13:40:29 vcore3 sudo[2272]: pam_unix(sudo:session): session opened for user root by blalor(uid=0)
Jul 02 13:40:34 vcore3 kernel: usb 1-1.2: reset full-speed USB device number 15 using xhci_hcd
Jul 02 13:40:34 vcore3 sudo[2272]: pam_unix(sudo:session): session closed for user root
Jul 02 13:40:34 vcore3 kernel: usb 1-1.2: device firmware changed
Jul 02 13:40:34 vcore3 kernel: usb 1-1.2: USB disconnect, device number 15
Jul 02 13:40:34 vcore3 kernel: usb 1-1.2: new full-speed USB device number 16 using xhci_hcd
Jul 02 13:40:34 vcore3 kernel: usb 1-1.2: unable to read config index 0 descriptor/all
Jul 02 13:40:34 vcore3 kernel: usb 1-1.2: can't read configurations, error -32
Jul 02 13:40:34 vcore3 kernel: usb 1-1.2: new full-speed USB device number 17 using xhci_hcd
Jul 02 13:40:34 vcore3 kernel: usb 1-1.2: device descriptor read/64, error -32
Jul 02 13:40:35 vcore3 kernel: usb 1-1.2: device descriptor read/64, error -32
Jul 02 13:40:35 vcore3 kernel: usb 1-1-port2: attempt power cycle
Jul 02 13:40:35 vcore3 kernel: usb 1-1.2: new full-speed USB device number 18 using xhci_hcd
Jul 02 13:40:35 vcore3 kernel: usb 1-1.2: Device not responding to setup address.
Jul 02 13:40:36 vcore3 kernel: usb 1-1.2: Device not responding to setup address.
Jul 02 13:40:36 vcore3 kernel: usb 1-1.2: device not accepting address 18, error -71
Jul 02 13:40:36 vcore3 kernel: usb 1-1.2: new full-speed USB device number 19 using xhci_hcd
Jul 02 13:40:36 vcore3 kernel: usb 1-1.2: unable to read config index 0 descriptor/all

There are no other USB devices plugged into the Pi.

After hitting the reset button, the board appears as a CAN interface, as expected:

Jul 02 13:44:18 vcore3 kernel: usb 1-1.2: new full-speed USB device number 20 using xhci_hcd
Jul 02 13:44:18 vcore3 kernel: usb 1-1.2: New USB device found, idVendor=1d50, idProduct=606f, bcdDevice= 0.00
Jul 02 13:44:18 vcore3 kernel: usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jul 02 13:44:18 vcore3 kernel: usb 1-1.2: Product: stm32f446xx
Jul 02 13:44:18 vcore3 kernel: usb 1-1.2: Manufacturer: Klipper
Jul 02 13:44:18 vcore3 kernel: usb 1-1.2: SerialNumber: btt-octopus-11
Jul 02 13:44:18 vcore3 kernel: gs_usb 1-1.2:1.0: Configuring for 1 interfaces
Jul 02 13:44:18 vcore3 mtp-probe[2366]: checking bus 1, device 20: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2"
Jul 02 13:44:18 vcore3 mtp-probe[2366]: bus: 1, device: 20 was not an MTP device
Jul 02 13:44:18 vcore3 mtp-probe[2373]: checking bus 1, device 20: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2"
Jul 02 13:44:18 vcore3 mtp-probe[2373]: bus: 1, device: 20 was not an MTP device
Jul 02 13:44:18 vcore3 systemd[1]: Found device stm32f446xx.
Jul 02 13:44:18 vcore3 systemd[1]: Started ifup for can0.
Jul 02 13:44:18 vcore3 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
Jul 02 13:44:18 vcore3 sh[2374]: can0=can0
root@vcore3:/home/pi/ksrc# ~pi/klippy-env/bin/python ~pi/klipper/scripts/canbus_query.py can0
Found canbus_uuid=4b8135060a45, Application: Klipper
Total 1 uuids found

I’ve gone back to usb/serial for now.

I’ve been successfully using this for a bit now, but I have one problem I haven’t resolved yet. I’ve changed the can0 interface to allow-hotplug as mentioned by leobg. This works, and after a restart or firmware_restart my can0 interface comes back up automatically. The issue I’m having is getting the other boards on the bus to reset. If I do consecutive restarts after a config change I can get all the boards back up sometimes, but if I do an e-stop, I haven’t been able to successfully bring up any boards on the bus other than the bridge board (Octopus). I get a failed automated reset error or an error stating the MCU can’t be updated as it’s shutdown. Once in this state I’m forced to power cycle the CAN boards to get Klipper back up. Hopefully this is something that can eventually be resolved.

I am observing the exact same behavior. E-stop would throw CAN connected boards into state that would not recover until power cycling the board power. If there is way to address that, CAN-bridge mode is production ready IMO.

I suspect this is due to reset ordering. The host will always reset [mcu] first followed by the secondary [mcu x] chips in the order they are defined in the config file. Unfortunately, this means that if a “bridge mcu” is reset before a canbus mcu, then the bridge wont be able to pass the reset signal along to the canbus mcu.

I’ll have to think about how to solve this. I suppose the host could detect bridge mcus and arrange to reset them last.

-Kevin

Thanks for this info Kevin. This allowed me to create a workaround. I renamed my bridge MCU to [mcu z], and one of my CAN boards to [mcu]. I then moved the bridge board to the bottom of the list in my config. This combined with using allow-hotplug has fixed the issue for me. After an e-stop, a firmware_restart brings up all of my boards properly with no issues.

The only downside to this solution is it took a bit of effort to fix all my pin names.

Power User, not a developer; I am working on instructions for this type of setup.
Octopus V1.0 Version: v0.10.0-521-gd91939c4

Having an issue of ‘Cannot find device “can0”’

  • I have setup my Octopus V1.0 F446 & Pro F446 with the compiled klipper.bin as shown above.
    CAN bridge on USB PA11/PA12 with CAN bus on PD0/PD1, speed 500000
  • Used stock bootloader with uSD card renamed klipper.bin to firmware.bin
  • After powering up the Octopus, the firmware.bin was renamed to FIRMWARE.CUR with firmware.bin not found on the uSD.
  • Powered down the Octopus.
  • Connected the USB cable between the Octopus and RPi
  • Power up the Octopus, then powered up the RPi.
  • Made the can0 file /etc/network/interfaces.d/can0 with allow-hotplug can0 and other additions for setup.
    allow-hotplug can0
    iface can0 can static
    bitrate 500000
    up ifconfig $IFACE txqueuelen 128
  • Rebooted RPi
  • Then checked for can0 with the ifconfig, none showing.
  • Then put in the command provided above in the discourse. sudo ip link set up can0 type can bitrate 500000
    This was when I got the above response ‘Cannot find device “can0”’

Note this last try was on a clean RPi OS lite 32bit Bullseye on an RPi 4B 4Gig.
sudo apt update
sudo apt dist-upgrade -y
sudo apt-get install git -y
cd ~
git clone GitHub - th33xitus/kiauh: Klipper Installation And Update Helper
Used KIAUH to install Klipper, Moonraker, Fluidd, and KlipperScreen (just on this try, testing new BTT PITFT50)

Please advise if I have missed something. I want to get this CAN bridge setup fully documented for other Octopus owners to try at their own risk.

Let me know what I can provide from this last attempt for your evaluation.

2 Likes

I also cannot get this to work with an SKR Octopus. After the firmware was flashed it is not recognized as CAN device.

dmesg
[ 808.813274] usb 6-1: new full-speed USB device number 9 using sunxi-ohci
[ 809.406735] usb 6-1: device not accepting address 9, error -62
[ 809.569984] usb 6-1: new full-speed USB device number 10 using sunxi-ohci
[ 809.777635] usb 6-1: device descriptor read/all, error -84
[ 809.783378] usb usb6-port1: attempt power cycle
[ 810.260090] usb 6-1: new full-speed USB device number 11 using sunxi-ohci
[ 810.294655] usb 6-1: device descriptor read/all, error -84
[ 810.463416] usb 6-1: new full-speed USB device number 12 using sunxi-ohci
[ 810.497694] usb 6-1: device descriptor read/all, error -84

I will try this again with an BTT U2C canbus adapter. This should also address the issues with firmware restart.