Firmware with USB to CANbus bridge broken for SKR Octopus (STM32F44)

[githubcura35]

I compiled a new firmware for my SKR Octopus with USB to CANbus bridge enabled but the board will not startup.

Steps to reproduce:

cd ~/klipper
git log
commit 3796a31 (HEAD -> master, origin/master, origin/HEAD)
Author: Kevin O'Connor kevin@koconnor.net
Date: Mon Jul 25 10:21:29 2022 -0400
git status
On branch master
Your branch is up to date with 'origin/master'.
make menuconfig

[*] Enable extra low-level configuration options
Micro-controller Architecture (STMicroelectronics STM32) --->
Processor model (STM32F446) --->
Bootloader offset (32KiB bootloader) --->
Clock Reference (12 MHz crystal) --->
Communication interface (USB to CAN bus bridge (USB on PA11/PA12)) --->
CAN bus interface (CAN bus (on PD0/PD1)) --->
USB ids --->
(500000) CAN bus speed

make clean
make
make flash FLASH_DEVICE=/dev/ttyACM1 #flashing via Canboot

Flashing out/klipper.bin to /dev/ttyACM1
Entering bootloader on /dev/ttyACM1
Device reconnect on /sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0
/usr/bin/python3 lib/canboot/flash_can.py -d /dev/serial/by-path/platform-3f980000.usb-usb-0:1.1.2:1.0 -f out/klipper.bin

Attempting to connect to bootloader
CanBoot Connected
Protocol Version: 1.0.0
Block Size: 64 bytes
Application Start: 0x8008000
MCU type: stm32f446xx
Flashing '/home/pi/klipper/out/klipper.bin'...

[##################################################]

Write complete: 2 pages
Verifying (block count = 442)...

[##################################################]

Verification Complete: SHA = 1A48D72ACDFF9FAD2877B79B18E1E0177E6E102C
CAN Flash Success

Flashing via SDCARD and df-util ends with same result:

dmesg

[ 2851.272041] usb 1-1.1.2: USB disconnect, device number 26
[ 2851.572518] usb 1-1.1.2: new full-speed USB device number 27 using dwc_otg
[ 2851.704574] usb 1-1.1.2: device descriptor read/all, error -32
[ 2851.812565] usb 1-1.1.2: new full-speed USB device number 28 using dwc_otg
[ 2851.922560] usb 1-1.1.2: device descriptor read/64, error -32
[ 2852.142599] usb 1-1.1.2: device descriptor read/64, error -32
[ 2852.262828] usb 1-1.1-port2: attempt power cycle
[ 2852.922564] usb 1-1.1.2: new full-speed USB device number 29 using dwc_otg
[ 2853.362627] usb 1-1.1.2: device not accepting address 29, error -32
[ 2853.462575] usb 1-1.1.2: new full-speed USB device number 30 using dwc_otg
[ 2853.509197] usb 1-1.1.2: device descriptor read/all, error -32
[ 2853.509301] usb 1-1.1-port2: unable to enumerate USB device
[ 2992.883491] usb 1-1.1.2: new full-speed USB device number 31 using dwc_otg
[ 2992.983488] usb 1-1.1.2: device descriptor read/64, error -32
[ 2993.203489] usb 1-1.1.2: device descriptor read/64, error -32
[ 2993.423485] usb 1-1.1.2: new full-speed USB device number 32 using dwc_otg
[ 2993.523479] usb 1-1.1.2: device descriptor read/64, error -32
[ 2993.743519] usb 1-1.1.2: device descriptor read/64, error -32
[ 2993.863587] usb 1-1.1-port2: attempt power cycle
[ 2994.523502] usb 1-1.1.2: new full-speed USB device number 33 using dwc_otg
[ 2994.963502] usb 1-1.1.2: device not accepting address 33, error -32
[ 2995.063499] usb 1-1.1.2: new full-speed USB device number 34 using dwc_otg
[ 2995.099949] usb 1-1.1.2: device descriptor read/all, error -32
[ 2995.100051] usb 1-1.1-port2: unable to enumerate USB device

cat /etc/network/interfaces.d/can0
allow-hotplug can0
iface can0 can static
bitrate 500000
up ifconfig $IFACE txqueuelen 128

[github-actions]

It looks like this ticket is a request for help (or similar). Many helpful people will not see your message here and you are unlikely to get a useful response. Instead, see the contact directions at: https://www.klipper3d.org/Contact.html

We use github to share the results of work done to improve Klipper. We don't use github for requests. (In particular, we don't use github for feature requests, to answer questions, nor to help diagnose problems with a printer.)

Please follow the directions at: https://www.klipper3d.org/Contact.html

This ticket will be automatically closed.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[Sineos]

Please open a topic on klipper.discourse.group. This is not the right place to discuss such topics as it focuses on Klipper development.

[githubcura35]

@Sineos I did and as it seems I am not the only one having this issue: https://klipper.discourse.group/t/experimental-usb-to-canbus-bridge-mode/3136/39. From my point of view there is a bug in the firmware. If this is not the right place to raise this then where?

[Sineos]

As you can already see from your link, the developers are already aware and reading here. No need to duplicate things

[jakep82]

I believe I responded to you on Discord. The issue is not Klipper. Multiple people have been unable to make bridge mode work with CanBoot. Switching back to the stock bootloader resolves the issue. I've been using my Octopus as a bridge since the original PR was posted with no issues.

[Arksine]

In my tests CanBoot works fine with bridge mode, however it is not possible to request the bootloader using bridge mode, so upgrading requires that you manually enter the bootloader. I will note that I haven't tested on an Octopus, so there could be some issue specific to that board I'm not aware of.

[githubcura35]

I was able to get get this to work on a BTT EBB wth canbus bridge mode but my Octopus is still fighting back.

[jakep82]

I tested last night and ran into the same issue as others. With the stock bootloader, bridge mode works fine. With only CanBoot the board enumerated fine, but as soon as I flashed Klipper it refused to enumerate again. I verified that I used the same 32k offset everywhere, and I compiled CanBoot for communication on USB PA11/PA12.

[githubcura35]

When I initially flashed the Octopus via SD card I had the same issue and it did not work. At that time there was no CanBoot installed.

[jakep82]

When I initially flashed the Octopus via SD card I had the same issue and it did not work. At that time there was no CanBoot installed.

It's working fine for multiple people including me using the stock bootloader. I would suggest switching back and trying again. I don't believe this is a Klipper issue.

[Drachenkaetzchen]

Octopus STM32F446 variant only

The issue here seems to be that several Octopus boards come from the factory with a problematic bootloader, and people are not aware of that issue.

You can revert to a known-good octopus bootloader by flashing the bootloader from BTT's GitHub. Put the Octopus into DFU mode first by installing the BOOT jumper, powering the board up and hit the RESET button on the board.

# Downloads the firmware file in Intel HEX format
wget https://raw.githubusercontent.com/bigtreetech/BIGTREETECH-OCTOPUS-V1.0/master/Firmware/DFU%20Update%20bootloader/bootloader/OctoPus-F446-bootloader-32KB.hex

# Converts the hex firmware to a bin
objcopy --input-target=ihex --output-target=binary OctoPus-F446-bootloader-32KB.hex bootloader.bin

# Optional: Backup the old bootloader
sudo dfu-util -d ,0483:df11 -R -a 0 -s 0x8000000:32768 -U old-bootloader.bin

# Install the new bootloader
sudo dfu-util -d ,0483:df11 -R -a 0 -s 0x8000000:leave -D bootloader.bin