Setup EBB36 v1.2 connected to Octopus pro

General Discussion
1

Basic Information:

Printer Model: V Core 3.1 500
MCU / Printerboard: btt Octopus Pro

Lets continue the klipper noob adventures.

For those already involved, thank you. The printer works and has printed a couple of calibration prints.

Has anyone any experience of setting you the ebb36 v1.2 with an octopus pro (and not use a can hat)

The GitHub - bigtreetech/EBB makes no sense to me. It appears to suggest install firmware_USB.bin onto ebb board and add the code from sample-bigtreetech-ebb-canbus-v1.2.cfg to printer cfg. But i can’t get that to work and the canbus / mcu isn’t visible.

I have also tried the instructions on the pdf ‘How to Use CAN Toolhead Boards Connected Directly to Octopus’ and got to near the end but no can0 on pi, and the octopus pro no longer had a boot loader.

Any ideas?

1 Like
2

Have you read this CANBUS Communication timeout while homing Z?

Good luck.

3

I literally got CanBoot working on an Octopus V1.1 with the SB2040 (Voron) and Octopus V1.1 with EBB/42 (Custom CoreXY) last night/this morning. It’s not a horrendous experience, but it is horrendously poorly documented with the various pieces of documentation in conflict internally and with one another as well as not using the most efficient methods for carrying out the various tasks (and requiring you to download and use applications which are the author’s favourites, but not well suited for the task at hand).

The best instructions I found are here:

Now, the menuconfig settings are the same between the Monster and the Octopus, the big difference between the two are:

  1. The Octopus does not have the CAN and USB select/enable jumpers
  2. When doing a `make configmenu’ for the Octopus, make sure you select an STM32F466 and the 12MHz clock (which should be the processor on the Octopus board that you have - I have three, all bought at different times, from different sources and they all have the F466 processor)
  3. The Octopus does have a boot jumper that needs to be installed as well as removing the USB power jumper (as is discussed on page 7 of How to Use CAN Toolhead Boards Connected Directly to Octopus.pdf and shown here:

image
image1745×1146 241 KB

Any time the Octopus needs to be programmed using DFU the “Boot0 Install Jumper” has to be in place and the Octopus’s reset button pressed before the DFU operation can take place. It’s a good idea to do the lsusb command to make sure the STMicroelectronics STM Device in DFU mode comes up (it should go away after you remove the jumper and reset the Octopus).

Now, I had quite a bit of trouble using an SD Card that was created using the Raspberry Pi imager for “Mainsail OS”. I should point out that I saved the previous SD Card and used a new one for this operation - I previously used a USB to Can (UtoC Can Hat) board, so I had some idea of what to look for in terms of getting CAN working.

When I created a new OS image for the SD Card to be loaded into the Raspberry Pi, selecting the “Raspberry Pi OS (32-bit)” - the first option for the Raspberry Pi Imager and then installed Klipper, Moonraker and Mainsail using KIAUH, according to the instructions in the page give above, things started working from here. I don’t know if it was because using the “Mainsail OS” image from the Raspberry Pi Imager had some kind of problem or I was getting better at things, but I was able to move through the instructions (restarting them for the nth time) much better than I could before.

In the document listed above, when you get to: klipper_canbus/monster8v2.md at main · maz0r/klipper_canbus · GitHub, I have no idea what “Unfortunatley in my own testing I could not get these alternate pins to connect to my EBB36v1.1 board (YMMV)” means. I would say, however, make sure you understand how you’re going to make up your CAN/Power cabling and have a high degree of confidence that it is wired correctly.

That’s it. I’m not sure of a couple of things:

  1. Why does the Octopus have to be programmed with a “CanBoot” firmware image, followed by a klipper image that sets up the USB as a pass through for the CAN bus? Does the “CanBoot” step load in something that isn’t overwritten by the klipper image write?
  2. What is the “CanBoot Deployer” that comes up when doing a menuconfig for the Octopus? The Arksine documentation is vague on it and not really clear on why somebody would use it, especially since I seem to be able to use CanBoot to update the firmware without it.

Along with “How to Use CAN Toolhead Boards Connected Directly to Octopus” I used the following resources:

Good luck - if I get some free time I’ll try to write up my own instructions, especially if I get some answres to the questions above.

2 Likes
4

You are an absolute star.

I will have a proper look and go through this process in the next few day.

Thank you.

1 Like
5

THIS IS ONLY INSTRUCTIONS FOR THE OCTOPUS BOARDS FOR CAN BUS BRIDGE.
Make sure you have the canboot.bin and klipper.bin ready before starting these steps. See below for make menuconfig settings for CanBoot and Klipper for your STM32 version.
We need the USB-C cable between the RPi and the Octopus.

Boot0 jumper location diagrams can be found at the bottom of this post.

  1. Octopus in DFU mode; jumper on the boot0, power up (Main or USB), and click the reset.
  2. Check for DFU in an ssh terminal, type in lsusb enter, and look for this ID for all STM32, 0483:df11

Loading CanBoot

  1. sudo dfu-util -a 0 -D ~/CanBoot/out/canboot.bin --dfuse-address 0x08000000:force:mass-erase -d 0483:df11 (this can take a little while)
  2. If you get an erase fail, you can run the following command; otherwise, proceed to step 5.
    sudo dfu-util -a 0 -D ~/CanBoot/out/canboot.bin --dfuse-address 0x08000000 -d 0483:df11
  3. For the Octopus, with the boot0 jumper still on, click the reset button to return to DFU mode.

Loading Klipper into place, this step will load klipper into the boot offset.
Copy this command for the Octopus boards.

  1. (STM32F466, F429, F407)
    sudo dfu-util -a 0 -D ~/klipper/out/klipper.bin --dfuse-address 0x08008000:leave -d 0483:df11
    (STM32H723)
    sudo dfu-util -a 0 -D ~/klipper/out/klipper.bin --dfuse-address 0x08020000:leave -d 0483:df11

  2. Octopus remove the boot0 jumper and reset the board.
    CanBoot and Klipper will be in place.

cd ~/CanBoot/scripts
python3 flash_can.py -q

STM32F466
image

STM32F429
image

STM32F407
image

STM32H723
image

BOOT0 jumper location on Octopus V1.0/1.1

image
image1596×1052 260 KB

BOOT0 jumper location on Octopus Pro Boards

image
image1599×1053 274 KB

2 Likes
6

@NAPCAL, while I appreciate you posting this, can I say that as somebody who just spent 12+ hours getting CAN running on the Octopus and CAN toolhead boards that your script wouldn’t be any more helpful to somebody who is new to setting up CAN on their Octopus than the other references found here, on Reddit and the various sundry places Google searches lead you to. At the very least, you need to add background and initial information as to what is being done and why.

Your use of DFU exclusively for firmware loading is different than that used by the other references linked to above and this difference, I think, helps me find an answer to one of my questions above.

Could I suggest you add to the beginning of your script:
a) An explanation of exactly what is happening in this process. A big thing that needs to be explained is why a canboot.bin image is first loaded into the Octopus (and the toolhead board) and is then followed by klipper.bin.
b) A set of instructions for downloading & installing CanBoot and PySerial?
c) Instructions for explicitly executing commands out of the CanBoot and klipper folders and running make (menuconfig|clean) from within them. You might also want to point out that the .bin files are in the out sub folder of CanBoot and klipper.

At the end of the script, could I suggest that you add:
a) Instructions for setting up the CAN bus on the Raspberry Pi (ie creating the “can0” file).
b) A brief outline of what needs to be done for a toolhead (or other) board that will be connected to the Octopus using CAN.

In going back to my questions above:

  1. In your process, you do two DFU loads of the Octopus, the first is of canboot.bin at 0x08000000 and the second is of klipper.bin at 0x08008000 - I suspect what is happening here is that canboot.bin (and the CanBoot functionality) is stored at a lower location in memory than the subsequent load of klipper.bin. This isn’t obvious from the two make menus where the “Bootloader offset” (CanBoot) is 32KiB, the same as “Application Start Offset” which I would have thought there’s a conflict/overwrite situation as the other installation guides use CanBoot for installing the Octopus’ klipper.bin file after using DFU for canboot.bin.

As somebody who has worked with various bootloaders over the years, I’m impressed that the klipper.bin file is relocatable - I think almost every other one I’ve worked with has required the start address of the application firmware must be stated explicitly and those that don’t, a special build process is required to make the generated code relocatable.

  1. Any idea what is the “CanBoot Deployer” that comes up when doing a CanBoot menuconfig for the Octopus? You have left “Build CanBoot deployment application” as “Do Not Build”.

Finally, can you comment as to whether or not there Is there any difference in how Klipper/Moonraker/Mainsail(Fluidd) is loaded using the Raspberry Pi Imager versus just loading the Raspberry Pi OS and then using KIUAH to load these applications? I think loading them via KIUAH ensures that they go in with only Python 3 (where as the Raspberry Pi Imager provides a Python 2/3 mix) - but this is only a theory.

Sorry for starting off this reply with my being negative about your process, I hope you understand that they come from somebody that has just climbed a mountain and understands exactly what you have put down (as well as knows it’s 100% right), but also knows it would not be helpful for somebody about to start their journey.

1 Like
7

@mykepredko
As for item 1.
It is unclear if using make FLASH will wipe the flash memory as suggested by Arksine the creator of CanBoot. So using dfu-util directly with the bootloader starting address and switches 0x08000000:force:mass-erase

Setting up CanBoot using the CAN bus port on the Octopus will not allow you access to loading klipper since this setup uses the klipper CAN bus bridge; this is the reason for the next step.

Also, it is unclear if make FLASH can load firmware into a custom address (application offset). So using dfu-util directly with the application offset and not using mass-erase switch will place klipper in the correct location in the flash memory.

As for item 2.

He states no bootloader, so CanBoot Deployer (deployer.bin) can not be used without a bootloader. However, the Deployer can be used to update CanBoot after it is in place and running. There is an issue since the Deployer wipes the flash, so klipper (can bus bridge) will not in place after the Deployer is used.

Sorry for the down-and-dirty instructions.
I am the admin and started the FB private BTT Octopus board owners group, 1.8K+ members, I have setup many Octopus boards with CAN bus, I don’t use or really like the CAN bridge via the Octopus, but so many don’t want to use RPi CAN hats or U2C adaptors.

I have setup many combinations of these CAN devices:
BTT U2C V1.1
BTT U2C V2.1
BIQU CAN hat V1
Seeed Studio 2-channel FDCAN hat
EBB42 F072
EBB42 G0B1
EBB36 G0B1
BIQU Hermit Crab CAN version
Octopus V1
Octopus Pro F466
Octopus Pro H723
SKR3
SKR3 EZ
EBB SB2240

1 Like
8

Thank you for the reply.

Item 1.

Could you explain “Setting up CanBoot using the CAN bus port on the Octopus will not allow you access to loading klipper since this setup uses the klipper CAN bus bridge; this is the reason for the next step.” I have had no problem using CanBoot to load two Octopuses/Octopi’s with klipper.bin after loading canboot.bin with DFU as per every other reference I can find on the subject. You’re an outlier on this issue and I’d like to understand why (in case I have an issue down the road).

Item 2.

Thank you for the explanation - that really isn’t clear on Arksine’s page.

Why don’t you like having the CAN bridge in the Octopus? It saves a bit of money and makes wiring things easier. I’ve printed enough since I got it running to feel like there isn’t a performance hit.

Hopefully you didn’t take from my comment that you don’t know what you’re doing - as I indicated what you put down matched my understanding of the process. My comments were noting that if you were to pass that post onto somebody who wanted to do it on their own, they probably wouldn’t be able to and would be coming back to you with questions.

9

I haven’t checked recently, but when I was using an Octopus in bridge mode it wasn’t possible to flash new versions of Klipper on the board without physical access to the board to enter the bootloader. This wasn’t a major issue because I typically go multiple months between updates, but it’s a hassle on my Voron to access the electronics. I’ve since switched to a different control board and a separate MKS CANable clone for ease of software updates.

1 Like
10

It is a hassle to access the Voron’s electronics - especially to put in an SD card.

Although I guess you could wire a switch across the Octopus’s Boot0 jumpers and program it using DFU.

When there’s an update to Klipper, I’ll build new versions fo the Octopus and the Toolhead boards and let everyone know how successful I was at using CanBoot for both.

11

@mykepredko
Item 1; jakep_82 has pointed out one part. The other is CanBoot doesn’t have a CAN bridge mode, and with the settings to have it communicate via CAN bus, it will not be able to communicate with the RPi without Klipper firmware up and running CAN bridge mode.

Item 2; with STM32F407, F429, and F466 having deal with Klipper firmware and CAN bridge code, seems to over tax the processor and the workload graphs don’t seem to include this information just Klipper itself. There have been users with this setup with data issues, stopped prints, or strange behavior.

Now the STM32H723 should have more than enough speed to overcome this issue.

12

4 posts were split to a new topic: CanBoot with USB to canbus bridge

13

Hi,

A question for @mykepredko (and everyone else).

I followed the MKS Monster instructions as linked above and all went as shown until it came to connecting the ebb36 board via the rj11 cable and got no such device exists. So I have a setting wrong somewhere.

So the MKS instructions for the CanBoot config shows communication interface as USB on PA11/PA12 but @NAPCAL’s reply shows this via Canbus on PD0/PD1. I went with the USB interface, is this correct?

I assumed that the MKS instructions referring to PA8/PA9 becomes PD0/PD1 on the Octopus Pro, but the Bigtreetech ebb36 github lists PB0/PB1?

14

@Julio
How do you want to connect the EBB36?

  1. USB to your RPi
    OR
  2. CAN bus to the Octopus board.
15

Hi @Julio

For The Octopus Pro,

Could you share:

  1. What is the MCU on your Octopus Pro? It should be printed with something like “STM32F429”.
  2. How you created your CanBoot and Klipper images for both the Octopus and EBB36 boards? Ideally screenshots of your make menuconfig setup.
  3. Provide pictures of your cabling?

As far as I know, all flavors of Octopus have their USB C on PA11/PA12 and CAN on PD0/PD1 and that’s shown on @NAPCAL 's post of four days ago.

16

Hi @NAPCAL and @mykepredko,

In answer to your questions.

Connect ebb36 to octopus pro via canbus

Octopus pro is stm32f446.

The installation process was copy pasted from the github page klipper_canbus/monster8v2.md at main ¡ maz0r/klipper_canbus ¡ GitHub with modifications as required then followed MELLOW FLY SHT 36/42 | klipper_canbus for the last bit

17

@Julio

Then the settings I posted are the settings you need to use for your Octopus.

The BTT EBB36 will need CanBoot loaded via USB-C, a jumper on the 120ohm header, and USB-C power. See “Loading CanBoot” in my Octopus post for DFU loading the CanBoot firmware to your BTT EBB36. See below for CanBoot and Klipper firmware settings.

You will need the following:
• USB-C cable between your RPi and the Octopus.
• RJ12 or RJ11 on the Octopus to the BTT EBB36 black connector.
• 24Volts to the BTT EBB36 to the black connector.

After setting up the Octopus Pro (CanBoot & Klipper) and getting CanBoot on the BTT EBB36.
Disconnect to USB-C cable from the BTT EBB36 and connect the CAN bus (CAN_L & CAN_H to the same) from the Octopus Pro to the BTT EBB36 (black connector). Connect 24Volts and ground to the BTT EBB36 (black connector). Remove the USB-C power jumper, or this may cause problems.
Power up RPi, Octopus Pro, and BTT EBB36.

via ssh terminal, type in the following: sudo nano /etc/network/interfaces.d/can0
copy this from here and paste it into the terminal.

allow-hotplug can0
iface can0 can static
bitrate 500000
up ifconfig $IFACE txqueuelen 1024

then Ctrl X
Y Enter to save the file.

then sudo reboot

ssh back into your RPi.
copy and paste this command: python3 ~/CanBoot/scripts/flash_can.py -q
Record the two UUIDs, the UUID that states Application: Klipper is your Octopus Pro, and the other is your BTT EBB36.

Ensure you have compiled your Klipper firmware for your BTT EBB36 before the last step.
copy and paste this command: python3 ~/CanBoot/scripts/flash_can.py -u
Replace the with the UUID of your BTT EBB36.

image
image2215×1081 150 KB

BTT EBB36 Pins

BTT EBB36 V1 [STM32F072]
image

BTT EBB36 V1.1 [STM32G0B1]
image

1 Like
18

(1) Make CanBoot Firmware
(1) Make CanBoot Firmware798×673 22 KB

(2) CanBoot Firmware
(2) CanBoot Firmware798×666 33 KB

(3) Build CanBoot Firmware
(3) Build CanBoot Firmware798×667 32.5 KB

(4) Flash CanBoot
(4) Flash CanBoot797×671 34 KB

(5) Verify CanBoot USB Bootloader
(5) Verify CanBoot USB Bootloader798×670 34.5 KB

(6) Make Klipper Firmware
(6) Make Klipper Firmware796×666 18.5 KB

(7) Flash Firmware via CanBoot
(7) Flash Firmware via CanBoot794×597 26.9 KB

(8) CAN0 Network
(8) CAN0 Network799×596 14.6 KB

(9) Verify Can Adapter
(9) Verify Can Adapter796×591 29.6 KB

(10) Verify Virtual Device
(10) Verify Virtual Device797×595 29.4 KB

(11) Check CAN0 is up
(11) Check CAN0 is up797×596 31.5 KB

(12) EBB36 CanBoot
(12) EBB36 CanBoot793×594 18.9 KB

(13) EBB36 Connected
(13) EBB36 Connected791×593 28.9 KB

(14) EBB36 Klipper Firmware
(14) EBB36 Klipper Firmware797×597 18 KB

(15) Flash to EBB36 Fail
(15) Flash to EBB36 Fail797×853 47.8 KB

Sorry For the length of the post, but this is all the screen shots of the ebb36 v1.2 / Octopus Pro canbus install. As you can see the final upload failed

19

image
image1179×781 93 KB

20

CanBoot for your Octopus Pro F466

image
image1179×1374 188 KB