not returning EBB36's UUID. Setup: Pi 4, Octopus v1.1, EBB36 v1.2


     problem: EBB36 CANBus UUID not output by script.
     cause: For me, a Hardware issue (?), EBB36 goes into DFU, allows uploading firmware via USB. But post firmware upload, the status LED doesn’t flash once per sec. This unexpected behavior indicates code is blocked/not-executing. My status LED was constantly dimly lit, don’t know if/what hardware fault that indicates.

    For other(s), they ran into Pi OS config issue, or something else…

     fix: For me, Buy another EBB36. Consider trash talking symptoms observed for the Poop one you have in this topic. Venting is cathartic, and info/context about your Poop EBB could help others.

    For other(s), installing MainSail Pi OS, before running Kaiuh scripts seemingly helped fix their OS config.

     my ask: Would appreciate learning more if someone encounters the same issues but has ST-Link/debugger to dig deeper into understanding what code is doing, and possibly root cause.



How do I lookup assigned CANBus UUID for a EBB36? How do I determine CanBoot and/or Klipper are running on the EBB36? Got logs and/or serial output that can be viewed if EBB36 is connected via both CANBus H/L (not power), but with 120R jumper, and USB-C (with VUSB jumper), and/or UART?

Ultimately, am trying to get this setup working… (with NO U2C board/hat) But am trying, and open to trying, various setups to help root cause and fix/work-around barriers.

Basic Information:

Printer Model: Pi 4 => Octopus v1.1 => EBB36 v1.2. Building a V1E MP3DP v4 CoreXY with 3 Z Steppers.
MCU / Printerboard: Octopus v1.1
Pushed recent klippy.log and
printer.cfg (rough work in progress…) to github.

:white_check_mark: Tried to self help via Knowledge Base

:white_check_mark: Tried to self help via this and this post***

    1. Check your wiring / jumper settings against the printer board specification.
      AZA: Done.
    1. Physically check the wiring
      AZA: Done, using twisted stranded 24 AWG copper (not CCA) from Cat 5 cable. End to end ~48" wire resistence is 0.5 Ohm.
    1. Start with a “bare metal” printer.cfg.
    • AZA: Sure, started with Voron Octopus cfg. Works fine when EBB mcu not specified.
    1. Take extra caution to have followed the official installation procedure.
    • AZA: Check and rechecked. Maybe I missed something, but can’t see it.
    1. Consult the klippy.log file
    • AZA: Done. Didn’t see ‘dirty’, there’s timeout connects. But it’s hard determine what’s relevant since exception logs are not date-time stamped. Honestly, I don’t fully understand the log content.
    1. Exclude faulty hardware
    • AZA: Created two separate CANBus wires, one per docs with CANBus high/low and 24V. Tested continuity and resistance. Since my understanding of the docs isn’t working out, to try and help narrow root cause, I also created 2nd cable with just CANBus high/low so EBB36 is powered from USB-C (with both 120R jumper and VUSB jumper).

Describe your issue:

Have been main following info from…

problem: Unable to find EBB36 CANBus ID. Looks like python3 ~/CanBoot/scripts/ -q only returns UUID unassigned based on Finding canbus_uuid docs. So, is the EBB36’s id ‘assigned’, if so what is it, or is there a problem with the cable and/or firmware installed?

Octopus v1.1 Klipper make menuconfig


EBB36 v1.2 Klipper make menuconfig


Note: Briefly tried ruling out CanBoot using EBB36 v1.2 Klipper config with no bootloader, with dfu-util to writing to 0x08000000 instead of 0x08008000. Still seeing same result as when I use documented guidance with CanBoot at 0x08008000


661wls@repeat: ~ $ cat /etc/network/interfaces.d/can0
allow-hotplug can0
iface can0 can static
bitrate 500000
up ifconfig $IFACE txqueuelen 1024

Commenting EBB36 from printer.cfg, with Octopus Klipper configured as USB to CAN bridge works fine.

Vaguely recall seeing EBB36 CANBus UUID was 127081e7e3c6 from earlier CANBus query output. However adding a reference to that CANBus MCU fails…


Save printer.cfg, restart of Klipper Host, and reset Octopus results in “Klipper is attempting to start” displayed for several minutes before Klipper Web UI eventually displays mcu connect failure…


Also, restart Firmware Restart doesn’t seem to work for Octopus configured with USB to CAN Bus bridge. I end up pressing Octopus’s physical Reset button. Firmware Restart seemed more reliable when Pi and Octopus communicate via Serial/Uart or USB.

Burnt bunch of time on this, if it’s easier and more reliable, am starting to become open to ditching Octopus’s onboard CanBus port and use a U2B board to help bridge EBB36 to Pi.

Have a scope I could use to probe CANBus H/L, but guessing there’s something obvious I’m missing. Used dfu-util to burn CanBoot and Klipper firmware to both EBB36 and Octopus. I did not use STM32CubeProgrammer.


From klippy log (trying diff cables, reversing CANBus high/low, ensuring 120R jumper on EBB, Octopus has two ~60 Ohm resistors in series, etc…)…

mcu 'mcu': Starting CAN connect
Created a socket
webhooks client 4129959264: New connection
webhooks client 4129959264: Client info {'program': 'Moonraker', 'version': 'v0.8.0-40-gb21f177'}
Loaded MCU 'mcu' 119 commands (v0.11.0-200-g7511151a / gcc: (15:8-2019-q3-1+b1) 8.3.1 20190703 (release) [gcc-8-branch revision 273027] binutils: (2.34-4+rpi1+14) 2.34)
mcu 'EBBCan': Starting CAN connect
Created a socket
mcu 'EBBCan': Timeout on connect
Created a socket
mcu 'EBBCan': Wait for identify_response
Traceback (most recent call last):
  File "/home/661wls/klipper/klippy/", line 68, in _get_identify_data
    params = self.send_with_response(msg, 'identify_response')
  File "/home/661wls/klipper/klippy/", line 261, in send_with_response
    return src.get_response([cmd], self.default_cmd_queue)
  File "/home/661wls/klipper/klippy/", line 318, in get_response
    self.serial.raw_send_wait_ack(cmds[-1], minclock, reqclock,
  File "/home/661wls/klipper/klippy/", line 253, in raw_send_wait_ack
    self._error("Serial connection closed")
  File "/home/661wls/klipper/klippy/", line 61, in _error
    raise error(self.warn_prefix + (msg % params))
serialhdl.error: mcu 'EBBCan': Serial connection closed
mcu 'EBBCan': Timeout on connect

Have you read klipper/ at master · Klipper3d/klipper · GitHub?

Good luck, hcet14

1 Like

Yep, appreciate you checking though. Man, there’s so many docs, and ways to trip up. Fortunately, I like puzzles :slight_smile: More importantly, I appreciate the community’s time and work that’s gone into this project. Cheers!

Have configured baud 500000 in can0 network interface file, CanBoot and Klipper firmware configurations for Octopus and EBB. Just noticed Klipper Docs > says baud defaults to 250000. Clutching at straws, I just tried adding “baud: 500000” to the section for EBB, but that doesn’t seem to be a supported config option :

baud: attribute not valid for CANBus based mcu?


Config error
Traceback (most recent call last):
  File "/home/661wls/klipper/klippy/", line 175, in _connect
  File "/home/661wls/klipper/klippy/", line 145, in _read_config
  File "/home/661wls/klipper/klippy/", line 304, in check_unused_options
    raise error("Option '%s' is not valid in section '%s'"
configparser.Error: Option 'baud' is not valid in section 'mcu ebbcan'

So, am figuring a logical next step is change baud from 500000 to 250000 for everything, reconfigure, recompile, reflash, reboot, etc…

Probably should have done that from the start, pick the lowest most reliable speed possible. Get end to end functionality working, the speed up from there.

  1. Any pointers on how to monitor, probe, listen EBB’s state would be greatly appreciated?
  2. How do you ‘unassign’ CANBus devices so they’ll be listed by the query scripts, or mod the query script to list all devices. Guessing broadcast like admin protocol has provision for this? Sorry am new to the code/project.

If the device has never worked in Klipper, then you don’t need to worry about unassigning it. For reference you can stop the Klipper service and press the reset button on the device to make it show up again when querying the bus for devices.

If you have flashed with dfu-util with no offset, then you no longer have a bootloader. I would start by flashing CanBoot on the EBB and see if it shows up on the CAN bus with only the bootloader running. Then flash the board with Klipper over the CAN bus instead of with dfu-util. Make sure when you do this that all devices are running at the same speed. If the Octopus is flashed at 500k, then every other device on the bus must also be 500k. That is not runtime configurable, and must be correct when compiling the firmware.

1 Like

Short: Still not seeing EBB CanBoot UUID being returned from :frowning: . Tried 3 diy CANBus cables. No EBB UUID regardless of whether or not scope/probes are attached. Used scope to observe Octopus sends something to EBB, that something is crisper with 120R jumper attached. Can’t see an easy way to physically probe rx/tx traffic on the STM32G0B1CBT6 PB0/PB1 side of EBB’s CANBus transceiver.

Still wondering how people monitor/debug code executing on EBB devices? Curious if people monitor debug output via USB, or hookup something (e.g. I2C display) to EBB’s I2C or some other pins? ST Link dongle, and STM32CubeProgrammer IDE’s debugger?


Changed Baud to 250k for /etc/network/interfaces.d/can0 , saved and rebooted Pi:

  • image

Configured 250K baud, rebuilt and deployed CanBoot for EBB36 and Octopus, same for Octopus klipper. E.g :

  • image

    make clean
    mv out/canboot.bin ebb_canboot.bin
  • Power down EBB36. Ensure power is only provided by USB-C, i.e. ensure CANBus cable not connected. Add jumper to VUSB header.

  • Power up EBB. Boot EBB36 into DFU mode (press and hold BOOT and RESET buttons, then release RESET before releasing BOOT).

  • Check Pi can see EBB36 is connected, and in DFU mode using lsusb. Output should include something like…

    • 0483:df11 STMicroelectronics STM Device in DFU Mode
    • Note the 0483:df11, use/substitute that identifier in the following steps.
  • Flash CanBoot firmware to EBB36…

    sudo dfu-util -a 0 -D ~/CanBoot/ebb_canboot.bin --dfuse-address 0x08000000:force:mass-erase:leave -d 0483:df11 
  • Similar for CanBoot on Octopus. For klipper Octopus didn’t force:mass-erase, used 8k offset 0x08008000.

While Klipper on Pi is stopped (sudo service klipper stop), after resetting Octopus, the scope shows CANBus High and Low at constant voltage of ~2.2V. Seems expected.

Running ~/CanBoot/scripts/ -i can0 -q results in signal being sent that oscillates between 1.15V and 3.4V. This seems expected based on CANBus protocol info. Interesting to me was that signal data continues to be sent from Octopus even after the query script has stopped executing. Resetting Octopus causes CANBus to go quiet with constant ~2.2V again.

Ordered another EBB36, arrives Sun. In the meantime will try out a U2C that recently arrived, in part because I found Klipper’s “Reset Firmware” feature more reliable for Octopus when not using USB to CAN bridge, but instead configured with regular USB or UART.


I have the same issue. I can not make Octopus v1.1 F446 in canbus bridge mode and EBB36 v1.2 work!

As far as I can tell, my wiring is OK, though I do not have an oscilloscope any other sophisticated tool to test. I have checked and even redone it, did not make a difference. Octopus has CanBoot and Klipper installed, it can be queried on CAN bus, if configured as mcu with can UID, Klipper is able to use it.

EBB36 has CanBoot installed (in DFU mode). Both CanBoot and Klipper were compiled by me (for Octopus also, freshly pulled from Github, CanBoot too), menuconfig was triple checked to use the same speed and correct pins/MHz/kB. The can0 interface appears to be up, when Klipper is configured to use Octopus as mcu, I can see TX/RX packet counters growing.

The 120R jumper is in place on the EBB36, I am not aware of Octopus having such a jumper.

I have started from scratch 2x, first with speed of 500000, second time with 250000. But nothing. EBB36 does not show up on the CAN bus as a CanBoot device, it can not be queried for its UID.

Currently I can think of either of three possible causes:

  • Despite the checks, my wiring is faulty.
  • My EBB36 is (partly) DOA.
  • Bug in hardware/firmware/software.

Can anyone point me to the right direction, or give some guidance on how to troubleshoot?


1 Like

I’ve used an Octopus in bridge mode with an EBB42, as have many other people, so I don’t think this is a bug.

1 Like

Hello @rokapet, appreciate knowing am not alone. Have also started from scratch a few times, tried both dfu-util and STM32CubeProgrammer to upload CanBoot firmware to the EBB36. Even tried uploading Klipper without CanBoot to EBB36 at 0x0800 0000.

Appreciate hearing from forum members that Pi 4 => Octopus v1.1 => EBB36 v1.2 combo is possible. Given that, am assuming this is a config/wiring issue on my part, and/or defective component(s). Given my assumptions, I didn’t even bother digging into repo history for recent changes in CanBoot or Klipper…

CanBoot configuration tried using for Octopus v.1.1 (no baud rate option, expected?)

Dug deeper into schematic and found that pins on the CANBus transceiver are large enough to be probed, can see CANBus high/low signals processed by the transceiver and be mapped to the RXD pin connected to EBB’s STM32’s CAN_RX PB0.

No data sent by EBB36 (CAN_TX, PB1). But signal is being received from Octopus to EBB’s CAN_RX, PB0. Without debugging, no idea whether EBB code treats that signal as valid packet data.

So, am seeing:

  • EBB36’s STM32 (CAN_TX, PB1) never attempts to send anything to CANBus transceiver’s TXD, voltage holds at ~3.95V. I suspect (CAN_RX, PB0) is receiving a signal, but am unclear on how to monitor whether EBB36 code is interpreting that signal as valid packet data, and/or what process it’s doing.
  • Resetting Octopus results in no traffic on Can High/Low, or EBB’s RXD/TXD. Until CANBus query script is executed.
  • After CANBus query script is executed Octopus seems to relentlessly send packets. Unfortunately, I don’t have a packet analyzer that can independently verify content, frequency or quality of my wiring from Octopus. No idea if Octopus being chatty is intentional/expected behavior.

Looking for a ST-Link and/or way to monitor debug output from the EBB36, and/or flash firmware with echo/ping functionality to help narrow down whether cause is config and/or hardware and/or software. Looks like PA13/PA14 are usually used for SWD debugging, but these are not easily exposed on EBB36. Hoping someone will point me in the right direction to help me dig deeper as to what EBB36 is up to. Cheers!

I think you’re digging too far into this. Have you confirmed that CanBoot is running on the EBB36? This can be done by configuring the status LED in CanBoot and verifying that the LED is flashing when the board is powered up. If it’s not flashing, CanBoot isn’t running. I only see the V1.1 board on the BTT GH, but I assume the schematic is the same so the LED should be on pin PA13.


For reference I just dug out my F446 Octopus and a V1.0 EBB42 and confirmed that everything is working with the latest Klipper. I have CanBoot on both boards, and the Octopus is running in bridge mode. The V1.0 board has the STM32F072 so it’s a little different, but it should still work on the STM32G0B1.

1 Like

Thank you for taking a look at your setup, and for the info @jakep_82.

Just tried (and failed) trying out the following…

  • Get latest sources, read recent edits…

  • Configure and build CanBoot for EBB36…

    • cd ~/CanBoot
      make clean
  • Prep EBB for flashing…

    • Remove 120R jumper. Add VUSB jumper.
    • Connect EBB36 via USB-C to Pi.
    • Boot into DFU (press both Boot and Reset buttons, release Reset first).
  • Check EBB is in DFU mode…


  • Ensure klipper not running on Pi…
    • sudo service klipper stop
  • Flash CanBoot to EBB…
    • sudo dfu-util -a 0 -D out/canboot.bin --dfuse-address 0x08000000:force:mass-erase:leave -d 0483:df11

  • Output mentions “Error during download get_status” but that seems common/harmless per other setup guides?

  • Switch EBB from USB-C to diy CANBus cable…

    • Remove USB-C
    • Move VUSB jumper to 120R jumper
    • Plug in diy CANBus cable
  • Reset Octopus

  • Run CANBus query script…


Expected Behavior : CANBus UUID for EBB and Octopus.
Actual Behavior : Only seeing UUID for Octopus.

Thanks for this…

Both the Power LED1, and the tiny Status LED2 on SWDIO/PA13 are constantly on, no flashing or pulsing. So maybe I’m flashing wrong and/or something’s up there…

Will double triple quadruple check, maybe hack Status LED flashing hello world just to verify I’m flashing firmware correctly…

If the LED isn’t flashing, then CanBoot didn’t flash properly. Until you see that LED flashing, you won’t see any results for the UUID when querying. Have you looked at the board to verify it definitely has the STM32G0B1 and not the STM32F072? I believe they still make and ship both versions.

1 Like

Good question.

Thanks for asking, I had checked the chip name before now. But I hadn’t taken a close look at whether any of the original solder needs checking and cleaning up.


Those bridges are definitely not good. Hopefully nothing is damaged.

1 Like

Try to remove the flux around the STM32. If you are lucky, there is no damage.

Good luck, hcet14

1 Like

Progress… Second EBB36 v1.2 just arrived, status LED flashes (1 sec on, 1 sec off) as expected after flashing CanBoot. Am calling the second EBB36 Chad

Configured, compiled and wrote CanBoot firmware to both EBB36’s exactly the same way using dfu-util, with PA13 set as the status LED.

My first EBB36 (Poop) has the LED constantly on. Notice how Poop’s status LED is much dimmer, maybe a short/drain somewhere?

To my untrained eye, Chad’s solder job is way cleaner cut… Poop has bunch of flux residue that looks very shiny under bright light, looks almost like solder in the pic here. In normal lighting conditions you can’t easily see the excess flux…

Chad Poop

A normal person would just throw Poop away at this point. Instead, might first use my FLIR to compare the boards and see if any shorts are hot enough to spot. Might clean my Poop with Isopropyl, and try again, before eventually throwing Poop back to BIQU.

Finally seeing a CANBus UUID for ‘Chad’ EBB36 :
~/CanBoot/scripts/ -i can0 -q

Hope info here helps others, and/or entertains them. Cheers for the guidance!

The flux is a little conducting (depends on the flux and how much). I’m positive your “Poop” is working after a clean out.

Amazing, never thought about that approach :grinning:

1 Like
  • Couldn’t see any interesting differences with FLIR, left both boards powered up for 15mins before using FLIR. I don’t have time, skill or tools to methodically probe further.
  • Tried cleaning Poop with Isopropyl. Still doesn’t look great under USB microscope. There’s more flux residue and pins look more oxidized.

Oh well, am returning Poop back to BIQU and moving on…

What is the “FLIR” that you are using?

When I’ve been involved in doing debug/failure analysis using heat detectors unless the sensor is actively cooled (ie by liquid nitrogen) you won’t get any meaningful results except in the case of something really blatant like a Vdd to Gnd/Vss short (in which case you should see charring of the PCB if not flames).

1 Like

Yeah, didn’t have high hopes, used a ~5yr old Seek Thermal Compact. Have a newer FLIR One Pro, but that’s loaned out to a friend.

Found the FLIR cameras mainly useful for providing insights on where am wasting money heating/cooling our home.