# CANBus\_Query.py not returning EBB36's UUID. Setup: Pi 4, Octopus v1.1, EBB36 v1.2 **URL:** \ **Category:** General Discussion\ **Created:** [May 18, 2023, 4:10am UTC](https://klipper.discourse.group/t/canbus-query-py-not-returning-ebb36s-uuid-setup-pi-4-octopus-v1-1-ebb36-v1-2/8464 "2023-05-18T04:10:15Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![azab2c](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/azab2c/32/5430_2.png) [@azab2c](https://klipper.discourse.group/u/azab2c)\ **Post date:** [May 18, 2023, 4:10am UTC](https://klipper.discourse.group/t/canbus-query-py-not-returning-ebb36s-uuid-setup-pi-4-octopus-v1-1-ebb36-v1-2/8464/1 "2023-05-18T04:10:15Z")
**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](https://klipper.discourse.group/t/canbus-query-py-not-returning-ebb36s-uuid-setup-pi-4-octopus-v1-1-ebb36-v1-2/8464/31), 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. **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. ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/d/d7bd8ef4c0263cc0bfafcd48957329677b608bb8.jpeg) ### 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](https://github.com/aaronse/v1engineering-mods/blob/main/mp3dp-v4/klipper/klippy.log) and [printer.cfg (rough work in progress…)](https://github.com/aaronse/v1engineering-mods/blob/main/mp3dp-v4/klipper/printer.cfg) to github. ✅ Tried to self help via [Knowledge Base](https://klipper.discourse.group/t/about-the-knowledge-base-category-table-of-contents/6228) - **EDIT:** Working through some KB articles, e.g. [Mcu: Serial connection closed / Timeout on connect / Wait for identify\_response](https://klipper.discourse.group/t/mcu-serial-connection-closed-timeout-on-connect-wait-for-identify-response/6645) ✅ Tried to self help via [this](https://klipper.discourse.group/t/how-to-trouble-shoot/6326) and [this](https://klipper.discourse.group/t/how-to-ask-for-help/6327) 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… - [Setup EBB36 v1.2 connected to Octopus pro](https://klipper.discourse.group/t/setup-ebb36-v1-2-connected-to-octopus-pro/6617) - Including [How to Use CAN Toolhead Boards Connected Directly to Octopus.pdf](https://klipper.discourse.group/uploads/short-url/oKyxrVja7wW0J8toGB1pqfaGp4z.pdf) and other guidance/docs both within, and referenced by the topic. - [KlipperMisc/BigTreeTech-EBB36-v1.1 at master · meteyou/KlipperMisc · GitHub](https://github.com/meteyou/KlipperMisc/tree/master/BigTreeTech-EBB36-v1.1) 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](https://www.klipper3d.org/CANBUS.html#finding-the-canbus_uuid-for-new-micro-controllers). So, is the EBB36’s id ‘assigned’, if so what is it, or is there a problem with the cable and/or firmware installed? ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/2/2e008d39d8c68b10c5a10c1a64be54c38a0eca98.png) ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/e/ea63f3ab6df2f5dd6d1c12374051d132f884ac59.png) ### Octopus v1.1 Klipper make menuconfig ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/7/78c6df1119dd7a5e81a8d1f4e9d04f6a4292ad6d.png) ### EBB36 v1.2 Klipper make menuconfig ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/7/751dda7f46ab70aefc381d79c08d3f5d586a8a4d.png) **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 ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/a/a67bd0fb0bf98160b216a909e7428297dd290f45.png) **661wls@repeat: ~ $ cat /etc/network/interfaces.d/can0** allow-hotplug can0 iface can0 can static bitrate 500000 up ifconfig $IFACE txqueuelen 1024 ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/5/55824a55cf3bfa0f7db8857c62883a92cc7773c6.png) Commenting EBB36 from printer.cfg, with Octopus Klipper configured as USB to CAN bridge works fine. ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/0/0a503ed595f37fca10256ebf4e98300c244b0049.png) Vaguely recall seeing EBB36 CANBus UUID was 127081e7e3c6 from earlier CANBus query output. However adding a reference to that CANBus MCU fails… ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/1/1f4254206f477d8cf68df22fcb265c9b11b38c20.png) 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… ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/c/cc653535736a7f2481eb8b6b75478c0d66488d82.png) ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/8/8ae307b36854e56a6d49e4b5c27dcbb84a215be7.jpeg) 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…)… ```auto 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 ``` ---
**Author:** ![hcet14](https://avatars.discourse-cdn.com/v4/letter/h/ecd19e/32.png) [@hcet14](https://klipper.discourse.group/u/hcet14)\ **Post date:** [May 18, 2023, 11:50am UTC](https://klipper.discourse.group/t/canbus-query-py-not-returning-ebb36s-uuid-setup-pi-4-octopus-v1-1-ebb36-v1-2/8464/2 "2023-05-18T11:50:06Z")
Have you read [klipper/CANBUS.md at master · Klipper3d/klipper · GitHub](https://github.com/Klipper3d/klipper/blob/master/docs/CANBUS.md)? Good luck, hcet14 ---
**Author:** ![azab2c](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/azab2c/32/5430_2.png) [@azab2c](https://klipper.discourse.group/u/azab2c)\ **Post date:** [May 18, 2023, 9:16pm UTC](https://klipper.discourse.group/t/canbus-query-py-not-returning-ebb36s-uuid-setup-pi-4-octopus-v1-1-ebb36-v1-2/8464/3 "2023-05-18T21:16:39Z")
Yep, appreciate you checking though. Man, there’s so many docs, and ways to trip up. Fortunately, I like puzzles 🙂 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 \> Config\_Reference.md#mcu](https://github.com/Klipper3d/klipper/blob/master/docs/Config_Reference.md#mcu) 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?** ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/f/fc496ced2ebd5082e9609ab0ce7e2696ec4dd947.png) ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/f/feac25e7d5b66fe12c01934e6746384168efc51b.png) ```auto Config error Traceback (most recent call last): File "/home/661wls/klipper/klippy/klippy.py", line 175, in _connect self._read_config() File "/home/661wls/klipper/klippy/klippy.py", line 145, in _read_config pconfig.check_unused_options(config) File "/home/661wls/klipper/klippy/configfile.py", 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. ---
**Author:** ![jakep\_82](https://avatars.discourse-cdn.com/v4/letter/j/ea666f/32.png) [@jakep\_82](https://klipper.discourse.group/u/jakep_82)\ **Post date:** [May 18, 2023, 9:52pm UTC](https://klipper.discourse.group/t/canbus-query-py-not-returning-ebb36s-uuid-setup-pi-4-octopus-v1-1-ebb36-v1-2/8464/4 "2023-05-18T21:52:41Z")
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. ---
**Author:** ![azab2c](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/azab2c/32/5430_2.png) [@azab2c](https://klipper.discourse.group/u/azab2c)\ **Post date:** [May 20, 2023, 2:57am UTC](https://klipper.discourse.group/t/canbus-query-py-not-returning-ebb36s-uuid-setup-pi-4-octopus-v1-1-ebb36-v1-2/8464/5 "2023-05-20T02:57:20Z")
**Short:** Still not seeing EBB CanBoot UUID being returned from canbus\_query.py ☹ . 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](https://www.digikey.com/en/products/detail/stmicroelectronics/STM32G0B1CBT6/18086231) PB0/PB1 side of EBB’s [CANBus transceiver](https://www.ti.com/lit/ds/symlink/sn65hvd1050.pdf). 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? **Long:** Changed Baud to 250k for /etc/network/interfaces.d/can0 , saved and rebooted Pi: - ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/d/dca6262ab7d0bcd07a1a8c6a35be1d53cdac9427.png) Configured 250K baud, rebuilt and deployed CanBoot for EBB36 and Octopus, same for Octopus klipper. E.g : - ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/0/03b3771b9050eb44ddecf0dab9cfbfe2fbff109e.png) - 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… - Flash CanBoot firmware to EBB36… - 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/flash_can.py -i can0 -q` results in signal being sent that oscillates between 1.15V and 3.4V. This seems expected based on [CANBus protocol info](https://en.wikipedia.org/wiki/CAN_bus). 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. ![IMG_20230519_193926_847](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/9/902e5f0d9d61fcfea25a9d0307558b2c0a5f315c.jpeg) 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. ---
**Author:** ![rokapet](https://avatars.discourse-cdn.com/v4/letter/r/e99b99/32.png) [@rokapet](https://klipper.discourse.group/u/rokapet)\ **Post date:** [May 20, 2023, 8:27pm UTC](https://klipper.discourse.group/t/canbus-query-py-not-returning-ebb36s-uuid-setup-pi-4-octopus-v1-1-ebb36-v1-2/8464/6 "2023-05-20T20:27:26Z")
Hi! 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? Thanks, Peter ---
**Author:** ![jakep\_82](https://avatars.discourse-cdn.com/v4/letter/j/ea666f/32.png) [@jakep\_82](https://klipper.discourse.group/u/jakep_82)\ **Post date:** [May 20, 2023, 8:54pm UTC](https://klipper.discourse.group/t/canbus-query-py-not-returning-ebb36s-uuid-setup-pi-4-octopus-v1-1-ebb36-v1-2/8464/7 "2023-05-20T20:54:43Z")
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. ---
**Author:** ![azab2c](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/azab2c/32/5430_2.png) [@azab2c](https://klipper.discourse.group/u/azab2c)\ **Post date:** [May 20, 2023, 9:49pm UTC](https://klipper.discourse.group/t/canbus-query-py-not-returning-ebb36s-uuid-setup-pi-4-octopus-v1-1-ebb36-v1-2/8464/8 "2023-05-20T21:49:16Z")
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?)** ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/f/fae381c006b86ac2fd5965fadd290dbecbeb15e7.png) 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. ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/4/4c88e1db054821d41c660f033fd5895627b57c14.jpeg) ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/c/ca817da8b3b807bb95a061f59be1af3642eb7fb8.jpeg) ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/3/330eafee85956269050dcd8902ddc1bf0207fbc5.jpeg) 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. ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/5/52e7728d1e7a66d8dc26261d38c82b8ce0954ca8.jpeg) 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! ---
**Author:** ![jakep\_82](https://avatars.discourse-cdn.com/v4/letter/j/ea666f/32.png) [@jakep\_82](https://klipper.discourse.group/u/jakep_82)\ **Post date:** [May 20, 2023, 10:36pm UTC](https://klipper.discourse.group/t/canbus-query-py-not-returning-ebb36s-uuid-setup-pi-4-octopus-v1-1-ebb36-v1-2/8464/9 "2023-05-20T22:36:17Z")
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. ---
**Author:** ![jakep\_82](https://avatars.discourse-cdn.com/v4/letter/j/ea666f/32.png) [@jakep\_82](https://klipper.discourse.group/u/jakep_82)\ **Post date:** [May 20, 2023, 10:39pm UTC](https://klipper.discourse.group/t/canbus-query-py-not-returning-ebb36s-uuid-setup-pi-4-octopus-v1-1-ebb36-v1-2/8464/10 "2023-05-20T22:39:19Z")
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. ---
**Author:** ![azab2c](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/azab2c/32/5430_2.png) [@azab2c](https://klipper.discourse.group/u/azab2c)\ **Post date:** [May 20, 2023, 10:41pm UTC](https://klipper.discourse.group/t/canbus-query-py-not-returning-ebb36s-uuid-setup-pi-4-octopus-v1-1-ebb36-v1-2/8464/11 "2023-05-20T22:41:24Z")
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… - Prep EBB for flashing… - Check EBB is in DFU mode… ```auto lsusb ``` ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/1/15f24a11b4b44375cdea6ed24563b9fd74fbc71c.png) - 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` ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/2/27835c84e4df99932de6b78b0ef70948f525476e.png) - 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… - Reset Octopus - Run CANBus query script… ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/6/6ad0395d7dc2d9649e44940cb0f65e390790ad07.png) Expected Behavior : CANBus UUID for EBB and Octopus. Actual Behavior : Only seeing UUID for Octopus. Thanks for this… > [@jakep\_82](#): > > 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. 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… ---
**Author:** ![jakep\_82](https://avatars.discourse-cdn.com/v4/letter/j/ea666f/32.png) [@jakep\_82](https://klipper.discourse.group/u/jakep_82)\ **Post date:** [May 21, 2023, 12:11am UTC](https://klipper.discourse.group/t/canbus-query-py-not-returning-ebb36s-uuid-setup-pi-4-octopus-v1-1-ebb36-v1-2/8464/12 "2023-05-21T00:11:18Z")
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. ---
**Author:** ![azab2c](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/azab2c/32/5430_2.png) [@azab2c](https://klipper.discourse.group/u/azab2c)\ **Post date:** [May 21, 2023, 12:53am UTC](https://klipper.discourse.group/t/canbus-query-py-not-returning-ebb36s-uuid-setup-pi-4-octopus-v1-1-ebb36-v1-2/8464/13 "2023-05-21T00:53:41Z")
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. ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/4/4dbac3d8b6dc3cb148fe45baeae0a4b5ac674a1c.jpeg) From [https://www.st.com/resource/en/datasheet/stm32g0b1ke.pdf](https://www.st.com/resource/en/datasheet/stm32g0b1ke.pdf) ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/2/26d3302501113809d2e2eb8c828313f2f0116386.png) ---
**Author:** ![jakep\_82](https://avatars.discourse-cdn.com/v4/letter/j/ea666f/32.png) [@jakep\_82](https://klipper.discourse.group/u/jakep_82)\ **Post date:** [May 21, 2023, 12:55am UTC](https://klipper.discourse.group/t/canbus-query-py-not-returning-ebb36s-uuid-setup-pi-4-octopus-v1-1-ebb36-v1-2/8464/14 "2023-05-21T00:55:42Z")
Those bridges are definitely not good. Hopefully nothing is damaged. ---
**Author:** ![hcet14](https://avatars.discourse-cdn.com/v4/letter/h/ecd19e/32.png) [@hcet14](https://klipper.discourse.group/u/hcet14)\ **Post date:** [May 21, 2023, 11:49am UTC](https://klipper.discourse.group/t/canbus-query-py-not-returning-ebb36s-uuid-setup-pi-4-octopus-v1-1-ebb36-v1-2/8464/15 "2023-05-21T11:49:24Z")
Try to remove the flux around the STM32. If you are lucky, there is no damage. Good luck, hcet14 ---
**Author:** ![azab2c](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/azab2c/32/5430_2.png) [@azab2c](https://klipper.discourse.group/u/azab2c)\ **Post date:** [May 21, 2023, 6:33pm UTC](https://klipper.discourse.group/t/canbus-query-py-not-returning-ebb36s-uuid-setup-pi-4-octopus-v1-1-ebb36-v1-2/8464/16 "2023-05-21T18:33:08Z")
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_ … ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/0/091ca2daf9699a7443c4425d46f47aaa3b223147.jpeg) 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** | | ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/3/391965f17c3d9c9c2a772307c4acc431c4ccc4b5.jpeg) | ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/3/3035b9da5cf78c8c342a986482d6e3348e11f82a.jpeg) | 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/flash_can.py -i can0 -q` ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/6/6cddfa7f571421cd1075c176f4f052c1a10de215.png) Hope info here helps others, and/or entertains them. Cheers for the guidance! ---
**Author:** ![hcet14](https://avatars.discourse-cdn.com/v4/letter/h/ecd19e/32.png) [@hcet14](https://klipper.discourse.group/u/hcet14)\ **Post date:** [May 21, 2023, 6:54pm UTC](https://klipper.discourse.group/t/canbus-query-py-not-returning-ebb36s-uuid-setup-pi-4-octopus-v1-1-ebb36-v1-2/8464/17 "2023-05-21T18:54:40Z")
> [@azab2c](#): > > My first EBB36 (_Poop_) has the LED constantly on. Notice how _Poop’s_ status LED is much dimmer, maybe a short/drain somewhere? The flux is a little conducting (depends on the flux and how much). I’m positive your “Poop” is working after a clean out. > [@azab2c](#): > > 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. Amazing, never thought about that approach 😀 ---
**Author:** ![azab2c](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/azab2c/32/5430_2.png) [@azab2c](https://klipper.discourse.group/u/azab2c)\ **Post date:** [May 21, 2023, 8:12pm UTC](https://klipper.discourse.group/t/canbus-query-py-not-returning-ebb36s-uuid-setup-pi-4-octopus-v1-1-ebb36-v1-2/8464/18 "2023-05-21T20:12:06Z")
- 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… ---
**Author:** ![mykepredko](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/mykepredko/32/2085_2.png) [@mykepredko](https://klipper.discourse.group/u/mykepredko)\ **Post date:** [May 21, 2023, 8:44pm UTC](https://klipper.discourse.group/t/canbus-query-py-not-returning-ebb36s-uuid-setup-pi-4-octopus-v1-1-ebb36-v1-2/8464/19 "2023-05-21T20:44:26Z")
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). ---
**Author:** ![azab2c](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/azab2c/32/5430_2.png) [@azab2c](https://klipper.discourse.group/u/azab2c)\ **Post date:** [May 21, 2023, 8:58pm UTC](https://klipper.discourse.group/t/canbus-query-py-not-returning-ebb36s-uuid-setup-pi-4-octopus-v1-1-ebb36-v1-2/8464/20 "2023-05-21T20:58:47Z")
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. [Next page](https://klipper.discourse.group/t/canbus-query-py-not-returning-ebb36s-uuid-setup-pi-4-octopus-v1-1-ebb36-v1-2/8464.md?page=2)