Jump to content
  • 5

Install CanBoot on SB2040



Hi everyone !

I got a Voron 2.4 controlled with a RP3 and an Octopus board. I want to upgrade it with a SB2040 from Mellow Fly, connected directly to the Octopus's canbus port. (Use a U2C or a canhat would be too easy).


But at the moment, Klipper can't connect to the octopus and the SB2040 seems unflashed (the blue LED which mean "firmware's running" remains off).

Sorry for the long post but, if it can help someone else, I have to detail everything. I did the following steps :

  • Make a CanBoot bootloader for the Octopus
  • Make a CanBoot bootloader for the SB2040
  • Flash the Octopus with STM32Cube Programmer and the CanBoot bootloader
  • Flash the SB2040 from the Raspberry PI and the Canboot bootloader
  • Make a Klipper bootloader for the Octopus
  • Make a Klipper bootloader for the SB2040
  • Flash the Octopus with the Raspberry PI and the Klipper bootloader
  • Flash the SB2040 throught the Octopus CanBus with the Klipper Bootloader
  • Then I cried 😥

The can0 interface is still setup (ifconfig), I got my two can_uuid :   [mcu] canbus_uuid: 3f56a5b6c36c ;  [mcu SB2040] canbus_uuid: 2d70e57a001c

But after I flashed the SB2040 through the canbus, his can_uuid disapeared. Of course, this probably comes from the fact that I can't use STM32Cube Programmer to make a "dual flash" ? I didn't truly understand the purpose of using STM32 Cube in that case.

I replaced the [mcu] section of the printer.cfg file with :

canbus_uuid: 3f56a5b6c36c

[mcu SB2040]
canbus_uuid: 2d70e57a001c



And the raspberry can't connect to the Octopus board. Klipper say : "mcu not available, try later". Not a surprise if Klipper is looking for the SB2040 mcu !

So, what did I miss ? Why after two flashs the SB2040 didn't have a firmware working ? Is there a software equivalent to STM32Cube to use with the RP2040 ?


Thank you for your help. I know that the Canboot project is very young, and I'm looking for troubles, but I hope that it will also help other peoples who face the same problem.

Link to comment
Share on other sites

Recommended Posts

  • 2

I just setup an SB2040 on my 2.4, it's working great so far. Have only done a few small PLA test prints, but it's working perfectly so far. Like you, I drew from a few documents to get it online, though the main one I'd recommend are the official Mellow docs here: Fly Klipper Docs (use the dropdown at the top to switch language, if you need to). Mellow also have a CanBoot page with some useful hints how to flash Klipper via CanBoot: CanBOOT (klipper.cn) The Klipper CANBUS pages can also come in useful: CANBUS - Klipper documentation (klipper3d.org).

At the time of writing, the Mellow CanBoot docs are missing a couple of images that show the firmware build configuration for CANBOOT and Klipper on the SB2040, so here they are:

My high-level setup is:

  • BTT Octopus 1.0 (non-pro) mainboard w/ Klipper built with CAN-bridge support (PD0/PD1, which are the CAN data pins in the RJ11 socket on the Octopus)
  • SB2040 flashed with CanBoot bootloader, and Klipper firmware built per the images linked above.

The Octopus works fine as a CAN bridge, you don't need any additional CAN/USB adapters or hats.

My process was more or less per the Mellow docs. I did this on the Voron's Pi over SSH - 

  1. Pull the latest Klipper (I used v0.10.0-623-g5b1a6676, CanBoot flashing is quite new, so you need a fairly recent version)
  2. "make menuconfig" and configure build for the Octopus:
    1. Arch: STM32
    2. Processor: STM32F446 (not all Octopus boards use the F446, use whatever matches your board)
    3. Bootloader offset: 32kb
    4. Clock: 12MHz
    5. Comm. interface: USB to CAN bus bridge (USB on PA11/PA12)
    6. CAN bus interface: PD0/PD1
    7. USB IDs: (default/CHIPID)
    8. CAN speed: 500,000
    9. GPIO pins: (none)
  3. "make" (build) Klipper for the mainboard, flash it using your preferred method. I use klipper/scripts/flash_usb.sh, or you can copy it to the SD card manually. Hard reset (power cycle) the board to load the new firmware.
  4. "git clone" CanBoot to your home directory and build per the Mellow screenshot:
    1.  Arch: RP2040
    2. Flash Chip: W25Q080 w/ CLKDIV2
    3. Deployer: Do not build
    4. Comm. interface: CAN bus
    5. CAN RX: 4
    6. CAN TX: 5
    7. CAN speed: 500,000
    8. GPIO on bootloader entry: (none)
    9. Support BL entry on double click: True
    10. Enable BL entry on button state: False
    11. Enable status LED: True
    12. Status LED pin: gpio24 
  5. Connect the SB2040 to the Pi via USB-C and flash CanBoot
  6. Disconnect the USB to the SB2040 and wire it up to your Octopus (the CAN data lines) and power from your PSU. At this stage you can install it in the toolhead if you want, since Klipper is flashed over CAN. Make sure you install the jumper cap on the SB2040 for the 120ohm CANBUS termination resistor. 
  7. Create the can0 interface: "/etc/network/interfaces.d/can0"
    allow-hotplug can0
    iface can0 can static
        bitrate 500000
        up ifconfig $IFACE txqueuelen 128

    Bring it online with "sudo ifup can0"

  8. Once you have everything wired and powered up you can query the CANBUS for UUIDs and start updating your Klipper config to connect to the Octopus over CAN instead of serial. Note - canbus_query only shows unassigned nodes. Once you configure Klipper to connect over CAN the device will stop appearing in the list.
  9. The SB2040 still needs to be flashed with Klipper. We've already installed CanBoot so we can flash it over the CANBUS. Build Klipper for the SB2040:
    1. Arch: RP2040
    2. Bootloader offset: 16kb
    3. Comm. interface: CAN
    4. CAN RX pin: 4
    5. CAN TX pin: 5
    6. CAN speed: 500,000
    7. GPIO pins on startup: gpio24
  10. Use "python3 ~/klipper/lib/canboot/flash_can.py -q" to check you can see your SB2040 in CanBoot mode on the CANBUS, and note it's UUID. 
  11. Flash the SB2040 with Klipper: "python3 ~/klipper/lib/canboot/flash_can.py -i can0 -f ~/klipper/out/klipper.bin -u <SB2040-UUID>"
  12. At this point you should have everything flashed and operational. FInish any toolhead wiring to the new board, update your Klipper config accordingly, and you should be good to go!
  13. (Optional) Add CanBoot to Moonraker's update manager:
    [update_manager CanBoot]
    type: git_repo
    path: /home/pi/CanBoot
    origin: https://github.com/Arksine/CanBoot.git

    This will just keep the cloned repo updated - it won't automatically flash new bootloader versions.

Hope this helps you figure out where yours is having trouble. If you're really stuck I'd try flashing the SB2040 with just Klipper and skip CanBoot for now. You can always re-flash it later.

Your issue with the status light may be that when you built the SB2040 bootloader or firmware you didn't configure the status LED correctly. The settings posted above are working for me.

Best of luck!

  • Like 3
  • Voron FTW! 1
  • Thanks 1
Link to comment
Share on other sites

  • 0


Sorry for abandoning the post. Thank you danja for your very complete answer. I hope it will help other peoples.

I have been waiting for the integration of the RP2040 in klipper. Now everything (almost) works fine. I was able to run a print correctly. But I can't run a test resonnance without the following error :


I can reach around 100Hz reducing the microsteps to 16 for each stepper.

Maybe 500 000kbps for the canbus is not enough ? Did someone try the input shaping with the SB2040 ?

Link to comment
Share on other sites

  • 0


I waited the last version of Klipper to support the Canboot bootloader on RP2040 (github link). So be sure you have the latest klipper version with kiauh, and the latest Canboot version (git pull command).

Then I reflashed the CanBoot on the SB2040 and the Octopus and I preciously write both uuids.

Everything seems to ok (except the can baudrate, I'm working on it).



Link to comment
Share on other sites

  • 0


On 12/6/2022 at 3:30 PM, Airborne Trooper said:

Can you take a picture how you have everything connected to the SB2040? I have one on the way and haven't seen any photos of them actually installed 

This is some photos of my setup.


For information :

  • I adapted almost every wires. (the red one is the klicky probe)
  • I cut the heatsink with a dremel for the TMC2209
  • I boosted the canbus to 1Mbs
  • I can't use the klicky probe or the ADXL with dynamic led effect (I use static led effects to lighten the load on the canbus

I highly recommand to add the following mod : https://www.printables.com/fr/model/300272-sb2040-fan-cover

I printed this mod without fan on the RP2040 and the mcu reach 80°C after around an hour (maybe more for the TMC2209). With a 24V 3010 fan it keeps the MCU under the 70°C even for long prints.


Edited by Flob74
  • Like 2
Link to comment
Share on other sites

  • 0

By order :

1 hour ago, Airborne Trooper said:

Thank you for the pictures. I have the fan from a pi kit. Curious why you’re still using cable chain after going canbus. I plan on using tap, klipper LED, and the onboard input shaper. Not sure why they would advertise it if you can’t use it. I do have a pi pico for input shaper in case. 

Because I find that the cable chain from the formbot kit was decent and it's a good cable management method. I planned to mount a USB cam on the gallery and I still have the 4 wires for hall enstops. I know that some will say that the ombilical is lighter, and cheaper but  just found it messy.

1 hour ago, Airborne Trooper said:

I plan on using tap, klipper LED, and the onboard input shaper.

I still have doubts about the new TAP mod. I'm really satisfied by my homemade klicky probe. (the original hall sensor from the kit wasn't reliable enough). I found it lighter and cheaper than the TAP and I'm sure that the plastic switch won't scratch my precious PEI bed. But I still have to learn about this mod and I hope that the future will prove me wrong.

By klipper led, you mean led_effect ? That a really really cool function ! I got 3 led strips of 20 leds and as I read somewhere : "I know exactly which program is running on the printer from the other side of the room !"


1 hour ago, Airborne Trooper said:

and the onboard input shaper. Not sure why they would advertise it if you can’t use it. I do have a pi pico for input shaper in case.

Technicaly, I can use the onboard ADXL to measure the resonance frequencies. And the SB2040 is build around the RP2040 MCU which is the heart of the pi pico. It's just that I'm using the BTT Octopus as CAN bridge. And maybe, in that specific case and without using a specific USB to CAN converter (I bought the UTOC anyway), it overload the can between the pi and the octopus, or the STM32 can't handle the load.

I couldn't use the ADXL with the 500kbits bus even without Klipper Led_effects. When I runned TEST_RESONANCES AXIS=X, at 100Hz I got the error "MCU 'mcu' shutdown: timer too close" and I had to restart the firmware. So I really took care about the can wire quality (contact, soldering, etc...) and I boosted the canbus to his limites at 1Mbits. It was enought to end both "TEST_RESONANCES" commands, get graphs.

Later I configured led effects and I discovereds that the error happend when I need to access quickly to the SB2040 while running an heavy led effect like the "rainbow" effect (ADXL, gantry levelling, etc...). But the led strip is runned by the octopus board, so I can't blame the SB2040 or his CanBus. Surprisingly, the tiny STM32F446 or the canbus seems to struggle to manage a 1Mbit/s CanBus, 60 leds at 24Hz, and get real time measurement from the SB2040.


I hope this will help you.

More informations in my other post :


Edited by Flob74
Link to comment
Share on other sites

  • 0

So... I've been quiet the last few weeks because I blew up my SB2040 when I was reattaching the front and misaligned the pins on the PCB header that connects the PCB in the front for the fans/LEDs to the main SB2040 board. I haven't worked out exactly which pins went where, but it was enough to let the magic smoke out and fry the board to a state beyond my abilities to repair. 😢 Of course it's my own dumb fault for carelessly jamming the headers together without looking closely they were aligned, and more to the point for working on it while the power was live - learn from my mistakes!

Anyway, I have a replacement board now and will get it wired back up in the near future for more CANBUS action! Somebody asked why you'd keep the drag chains with the SB2040? Well, they are handy for when you blow it up and need to quickly switch back to the BOM cables! 😉 I might drop them at some point once I've got the SB2040 fully established. 

@Flob74 Love the fan cover mod, will definitely by trying that out. I've been a little curious about how the MCU temps hold up during long print runs. It didn't complain in my earlier tests, but they were fairly small prints, not more than 2-3 hours. I think it was hovering around ~70c, which IMO is on the high side of acceptable... I wouldn't want it above ~80c for extended periods if possible (RP2040 specs state -40 to 85c as the min/max service temps).

I believe there is also some dynamic clock adjustment features in the RP2040 to downclock the chip if it gets too hot, though I'm not sure if these are active on the SB2040 implementation.

@Flob74 Did you notice any issues after increasing the CANBUS speed to 1Kbps? Also, curious if you're now on Klipper 0.11.x as it looks like there was a bit of a CANBUS focus in this release - not sure if it's improved any of the data/speed-related issues you mentioned around LED effects/input shaper?

  • Like 1
Link to comment
Share on other sites

  • 0
6 hours ago, danja said:

Well, they are handy for when you blow it up and need to quickly switch back to the BOM cables!

Prescience, always a very useful talent to have 😉

6 hours ago, danja said:

some dynamic clock adjustment features in the RP2040 to downclock the chip

Interesting to know, as that could be more of a curse than blessing and result in some nasty issues if all of a sudden your tool-head suddenly stops processing klippers commands at an appropriate rate. As you say I think 70C is probably the high end of acceptability (it's certainly breaching the "80% rule" of the 85C max). That suggests to me some sort of cooling is required (which naturally will bring it's own challenges).

Link to comment
Share on other sites

  • 0

Thank you for sharing your experience (RIP little PCB that left us too soon).

12 hours ago, danja said:

Did you notice any issues after increasing the CANBUS speed to 1Kbps?

Either I didn't notice anything, or it's the root of all my problems. I updated to the last Klipper version 0.11 and I didn't noticed any change.

I tried to print voron's skirt parts but after around 3 or 4 hours printing ABS, I jammed the hotend. I suspect the heatchamber to reach more than 80°C after some hours. My Voron is really well enclosed and I don't have air extractor. So my next goal is to print an air extractor with a fan to PID regulate the heatchamber temperature.

Edited by Flob74
Link to comment
Share on other sites

  • 0

If I can help, there is not rocket science in the wiring. It's the same as the hartk 2pcbs mod.

For the LED strip, there is 3 pins for signal, 5V, GND.

For fans :

  • Choose wisely the Vcc pins for fans (24V or 5V)
  • AGND mean "PWM controlled GND".
  • for PWM and GND pads I suppose that they are here for RGB fans.

Same for the FAN N°2 : choose wisely Vcc between 24V and 5V and use AGND for PWM control.

Edited by Flob74
  • Like 1
Link to comment
Share on other sites

  • 0


Was able to get the FLY-2040 connected directly to the Octopus 1.1 over CANBUS and am able to query the accelerometer and see the MCU and enclosure temps etc

I am wondering if anyone knows why the enclosure temp (sb2040:gpio26) is about 17 deg greater than the extruder and heater bed temps

[temperature_sensor Enclosure]
sensor_type = ATC Semitec 104GT-2
sensor_pin = sb2040:gpio26

Link to comment
Share on other sites

  • 0
1 hour ago, lemmingDev said:

If I set 

[temperature_sensor Enclosure]
sensor_type = ATC Semitec 104GT-2
sensor_pin = sb2040:gpio26
pullup_resistor: 10000

I seem to get a similar temperature (within 1 deg) to the other temps 

Seems odd, this was working fine for me on my first board (before I blew it up):

## SB2040 Onboard NTC100K thermistor
[temperature_sensor Toolhead-PCB]
sensor_type: ATC Semitec 104GT-2
sensor_pin: sb2040:gpio26
min_temp: -50
max_temp: 100

I'm in the process of installing my second SB2040, and I'll post an update once that's done if this still works.


Link to comment
Share on other sites

  • 0
On 12/24/2022 at 5:21 PM, lemmingDev said:

Let me know how you go...

Got the new board up and running yesterday, and ran into the same issue with the onboard NTC 100K sensor. It was reporting ~70c in a ~25c ambient room. I tried a few variations of sensor_type and pullup_resistor, and landed on the same combination you did (ATC Semitec 104GT-2 w/ 10k pullup). 

According to the schematics, the pullup should be 4.7k, same as the default pullup_resistor value in Klipper, so my guess is Mellow may have either messed up/changed the pullup value, or changed the NTC sensor type. If I knew where the pullup and NTC were actually located on the board I'd measure them with a multimeter, but I can't easily tell which microscopic SMD component is the sensor/pullup on the physical board.. 


This is the config I've got at the moment - using it to control the chamber exhaust fan instead of just a passive sensor value:

[temperature_fan chamber]
pin: PD12 # Exhaust fan - CNC_FAN2 on Octopus
max_power: 0.5
shutdown_speed: 0.0
kick_start_time: 0.3
cycle_time: 0.01
off_below: 0.1
sensor_type: ATC Semitec 104GT-2
pullup_resistor: 10000
sensor_pin: sb2040:gpio26
min_temp: 0 
max_temp: 100
target_temp: 45
control: watermark
gcode_id: C

Edit: I should point out that this config isn't fully validated in my mind yet. It seems to be reporting sensible values, but I've not done anything yet to verify the accuracy. I'll probably hook up another known-good sensor to the main MCU, place it somewhere near the SB2040 and check the temps reported are similar over the ~20-60c range. Till then I consider the value reported a little suspect.

Edited by danja
Added disclaimer
Link to comment
Share on other sites

  • 0

Hi I read this thread so many times trying to get my SB2040 and BTT Octopus 1.1 talking that I probably memorised part of it by now. Many thanks especially to @danja on the details you posted.

I was almost ready to post a help message here as I could not get my can0 up and running no matter what I did. Some how managed to get it up using this guide https://github.com/akhamar/voron_canbus_octopus_sb2040#useful-tricks-to-be-able-to-update-an-octopus-11-in-usb-to-can-bridge

I am actually using pretty much the this guide for my setup now.

For those like me who had problems getting your can0 up, I tried running:

systemctl stop klipper



Running these two managed to bring my can0 up. Hope this helps someone else.




Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...