Short:
problem: EBB36 CANBus UUID not output by canbus_query.py 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.
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.
Long…
Hello!
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.
Tried to self help via Knowledge Base
- EDIT: Working through some KB articles, e.g. Mcu: Serial connection closed / Timeout on connect / Wait for identify_response
Tried to self help via this and this post***
-
- Check your wiring / jumper settings against the printer board specification.
AZA: Done.
- Check your wiring / jumper settings against the printer board specification.
-
- 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.
- Physically check the wiring
-
- Start with a “bare metal” printer.cfg.
- AZA: Sure, started with Voron Octopus cfg. Works fine when EBB mcu not specified.
-
- Take extra caution to have followed the official installation procedure.
- AZA: Check and rechecked. Maybe I missed something, but can’t see it.
-
- 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.
-
- 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…
-
Setup EBB36 v1.2 connected to Octopus pro
- Including How to Use CAN Toolhead Boards Connected Directly to Octopus.pdf and other guidance/docs both within, and referenced by the topic.
- KlipperMisc/BigTreeTech-EBB36-v1.1 at master · meteyou/KlipperMisc · GitHub
problem: Unable to find EBB36 CANBus ID. Looks like python3 ~/CanBoot/scripts/flash_can.py -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.
Cheers!
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 'mcu' config: ADC_MAX=4095 BUS_PINS_i2c1=PB6,PB7 BUS_PINS_i2c1a=PB8,PB9 BUS_PINS_i2c2=PB10,PB11 BUS_PINS_i2c3=PA8,PC9 BUS_PINS_sdio=PC12,PD2,PC8,PC9,PC10,PC11 BUS_PINS_spi1=PA6,PA7,PA5 BUS_PINS_spi1a=PB4,PB5,PB3 BUS_PINS_spi2=PB14,PB15,PB13 BUS_PINS_spi2a=PC2,PC3,PB10 BUS_PINS_spi3=PB4,PB5,PB3 BUS_PINS_spi3a=PC11,PC12,PC10 BUS_PINS_spi4=PE13,PE14,PE12 CANBUS_BRIDGE=1 CLOCK_FREQ=180000000 MCU=stm32f446xx PWM_MAX=255 RECEIVE_WINDOW=192 RESERVE_PINS_CAN=PD0,PD1 RESERVE_PINS_USB=PA11,PA12 RESERVE_PINS_crystal=PH0,PH1 STATS_SUMSQ_BASE=256 STEPPER_BOTH_EDGE=1
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/serialhdl.py", line 68, in _get_identify_data
params = self.send_with_response(msg, 'identify_response')
File "/home/661wls/klipper/klippy/serialhdl.py", line 261, in send_with_response
return src.get_response([cmd], self.default_cmd_queue)
File "/home/661wls/klipper/klippy/serialhdl.py", line 318, in get_response
self.serial.raw_send_wait_ack(cmds[-1], minclock, reqclock,
File "/home/661wls/klipper/klippy/serialhdl.py", line 253, in raw_send_wait_ack
self._error("Serial connection closed")
File "/home/661wls/klipper/klippy/serialhdl.py", line 61, in _error
raise error(self.warn_prefix + (msg % params))
serialhdl.error: mcu 'EBBCan': Serial connection closed
mcu 'EBBCan': Timeout on connect
More importantly, I appreciate the community’s time and work that’s gone into this project. Cheers!
. 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 
