Canboard.... my war

General Discussion
1

Basic Information:

Printer Model: Vcore 3.1
MCU / Printerboard: Octopus Pro + EBB42 by Canbus
klippy.log

Fill out above information and in all cases attach your klippy.log file. Pasting your printer.cfg is not needed
Be sure to check our Knowledge Base and in particular this and this post

Describe your issue

Hi,

Some time ago I used this forum to configure an EBB42 board for Canbus, and after many attempts, and thanks to the help of some Forum users, I managed to configure it.

Since then I have been using it, and it is the best upgrade I have been able to do to the printer, it works very well. I only have some disconnection when I do Ztilt, but it never once starts to print…

The issue is that after a few months of use, I want to update the firmware, but at the time I did not take notes on the procedure to follow for the update, and tried to follow any of the guides with 0 success…

So one option that I want to try is something that @NAPCAL recommended to me in this post (Bootloader in Canboard) , but I have some doubts…

  • If I manage to carry out this procedure, and I have not misunderstood… Will I be able to update the EBB42 through the CAN connection?
  • What would be the procedure for updating the firmware of the EBB?
  • I’m not sure, I think that back in the day I set the speed to the interface CAN0=500000, and I thought I read that with the new firmware the recommended speed was CAN0=1000000 (maybe this helps the disconnections I have when I do ZTilt)

I apologize for any mistakes I may make…

I take the opportunity to ask another question.

I connect ONLY by USB the EBB42 to the rPi
I do the Reset/Boot procedure, to put it in DFU mode
console command to rPi (lsusb)

And the EBB does not appear
Could it be because it is flashed to work on CANBUS? or should i watch it?

2

@Peurif

Yes, you can update CanBoot or Klipper via the CAN bus.

We need to stop the Klipper service first then start it back running after you complete your update.
sudo service klipper stop
sudo service klipper start

Make sure to compile the new Klipper firmware before running the script below.

  • to update Klipper after getting CanBoot in place.
    python3 ~/CanBoot/scripts/flash_can.py -u
    flash_can.py defaults to can0 and ~/klipper/out/klipper.bin so not necessary
    Replace with the uuid of the board to update.

Make sure to compile the new CanBoot with the deployer option set, this will create deployer.bin in the ~/CanBoot/out/ folder. Also, compile Klipper for this board you are updating since the deployer.bin will wipe flash memory space outside of CanBoot.

  • to update CanBoot
    python3 ~/CanBoot/scripts/flash_can.py -f ~/CanBoot/out/deployer.bin -u
  • python3 ~/CanBoot/scripts/flash_can.py -u
    Replace with the uuid of the board to update.
3

I notice that I am very close, but something is wrong.

The CanBoard that I had configured, an Ebb42, works configured by CanBus, not USB.

Following one of the guides that you recommended me some time ago:

I have managed to get it to work… I have achieved that when I send the command through the console:

~/klippy-env/bin/python ~/klipper/scripts/canbus_query.py can0

he answers me:

“Found canbus_uuid=XXXXXXXXX, Application: CanBoot”

Giving me instead of XXXXXXXXX, a value that I don’t remember now… well, it seems that it will work, but NO.

When I put that UUID in the configuration, FLUIDD gives me an error message that it doesn’t detect it, however if I connect through the console and send the above command, it gives me the UUID…

And if I connect the previous EBB42, which works, but it’s outdated, and I change its UUID in the configuration, it does work…

In short, the new EBB v1.1 with the new firmware is detected by Raspberry PI, but I can’t get it configured in FLUIDD.

However, the old EBB v1.1 with the older firmware is detected by the Raspberry Pi, and DOES work on FLUIDD.

(I have done tests with and without terminal jumper on, the same thing)

Some idea what i am doing wrong?

4

You should use my guide.
Octopus, EBB, CanBoot, Klipper, CAN bridge(2023-03-25).pdf

5

thx… tomorrow see
Thx

1 Like
6

This morning I have reviewed the steps, and I have found something that may cause me the error.

Let’s remember that the error is that the old EBB42 with the previous firmware works correctly, but if I try to configure a new EBB42 that I have in reserve, I can’t get it to work. I do find the UUID, but I can’t get Fluidd to find it…

I have reviewed the steps and I have realized that I think the interfaces file has the wrong name instead of “can0”, the name it has is “can.0”

Can0 name error

So very possibly this gives me the error, but of course… now it’s working, which means that rPi will be taking the CAN0 interface configuration from another site, if I change it I risk that neither the new nor the old one will work.

  • Is there any way to know what values rPi is taking for CAN0?

  • Is it possible that this error in the name causes me the error that I have explained before? rPi finds the UUID of the EBB42, but klipper does NOT connect to it

7

The file should be just can0 not can.0
Rename if possible or delete and recreate.

8

I suposse these, but…

Why its working?

9

Linux got me.
ifconfig to see if it shows as can0 or can.0

10

Not sure if i have plugged Canboard (Ebb42)

Linux fluiddpi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sun Jun 18 07:07:49 2023 from 192.168.1.136
SSH is enabled and the default password for the ‘pi’ user has not been changed.
This is a security risk - please login as the ‘pi’ user and type ‘passwd’ to set a
new password.
pi@fluiddpi:~ $ ifconfig
can0: flags=193<UP,RUNNING,NOARP> mtu 16
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 1024
(UNSPEC)
RX packets 187786 bytes 1419607 (1.3 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 21142 bytes 126691 (123.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.200 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 2a0c:5a84:a104:4500:df8d:9722:42c5:b4bc prefixlen 64 scopeid 0x0
inet6 fe80::6039:cc32:598e:76fe prefixlen 64 scopeid 0x20
ether e4:5f:01:e1:39:2d txqueuelen 1000 (Ethernet)
RX packets 28410 bytes 5825755 (5.5 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1977 bytes 225137 (219.8 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1000 (Local Loopback)
RX packets 11 bytes 1640 (1.6 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 11 bytes 1640 (1.6 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether e4:5f:01:e1:39:2e txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
pi@fluiddpi:~ $

11

I figured out that it is just a file; inside that file, it has entries for can0, so the filename doesn’t matter.

12

Hi,

I have tried to follow the guide again, but in step 8 where klipper flashes in the EBB for the second time. Which I don’t quite understand, because I thought it had already been flashed… it gives an error message, and from that moment it’s as if the EBB had disappeared. I run the script to find the UUID and it doesn’t find it.

The script I’m trying to run is:

python3 ~/CanBoot/scripts/flash_can.py -u 3ad286d6058d

And the error message:

pi@fluiddpi:~ $ python3 ~/CanBoot/scripts/flash_can.py -u 3ad286d6058d
Sending bootloader jump command…
Resetting all bootloader node IDs…
Checking for canboot nodes…
Detected UUID: 3ad286d6058d, Application: CanBoot
Attempting to connect to bootloader
CanBoot Connected
Protocol Version: 1.0.0
Block Size: 64 bytes
Application Start: 0x8002000
MCU type: stm32g0b1xx
Verifying canbus connection
Flashing ‘/home/pi/klipper/out/klipper.bin’…

[####ERROR:root:Can Flash Error
Traceback (most recent call last):
File “/home/pi/CanBoot/scripts/flash_can.py”, line 483, in run
await flasher.send_file()
File “/home/pi/CanBoot/scripts/flash_can.py”, line 214, in send_file
resp = await self.send_command(‘SEND_BLOCK’, prefix + buf)
File “/home/pi/CanBoot/scripts/flash_can.py”, line 193, in send_command
raise FlashCanError(“Error sending command [%s] to Can Device”
FlashCanError: Error sending command [SEND_BLOCK] to Can Device

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File “/home/pi/CanBoot/scripts/flash_can.py”, line 628, in main
loop.run_until_complete(sock.run(intf, uuid, fpath, req_only))
File “/usr/lib/python3.9/asyncio/base_events.py”, line 642, in run_until_complete
return future.result()
File “/home/pi/CanBoot/scripts/flash_can.py”, line 489, in run
await flasher.finish()
File “/home/pi/CanBoot/scripts/flash_can.py”, line 272, in finish
await self.send_command(“COMPLETE”)
File “/home/pi/CanBoot/scripts/flash_can.py”, line 193, in send_command
raise FlashCanError(“Error sending command [%s] to Can Device”
FlashCanError: Error sending command [COMPLETE] to Can Device

13

Yes, you flash CanBoot to the EBB, but we are going to flash Klipper via the CAN bus to make sure everything is working.

You more than likely didn’t complete the Klipper firmware compile for the EBB

1 Like
14

One thing that was not clear to me was that the EBB has two firmwares, the Canbus and the Klipper

as i am having some problems to flash these firmwares by console, i can…

1- Compile the firmware by the method explained in the guide (make menuconfig)
2 - Copy them to the PC
3- Flash them with STM32 cube programming

That program at the moment has not given any errors, and with the console… buff

15

CanBoot is the bootloader and Klipper is the printer firmware.

16

The results of the tests that I have done this afternoon have not been good.

I explain more or less what I have done:

1- I have compiled the CanBus firmware
2- I have compiled the Klipper firmware
3- From a PC I have recorded the CanBus firmware in the EBB via USB, with STM32…
4- To test, I have connected the EBB42 with the CANBUS firmware, and through the console I have seen that rPi detected the EBB42 and assigned a UUID to it
5- The UUID thus obtained I have put in the Fluidd configuration where I have the UUID of the EBB42 that I do not know how, yes it works
6- But Fluidd doesn’t detect it, I thought I needed to flash the Klipper firmware to the EBB42
7- Again with STM32, I have flashed the Klipper firmware on the EBB42
8- I have connected it by CANBUS, and where before if rPI detected it and gave me the UUID, now it does not detect it…

What am I doing wrong?

Note: I don’t care if in the future to update the EBB42 I have to do it from a PC via USB…

17

If you look at my guide, you will see that CanBoot loads at the start of the flash memory, then Klipper loads at the application offset.

Using STM32CubleProgramer without altering the memory offset for Klipper, it will load over the same location as CanBoot, destroying its code. This will not run correctly because Klipper code is all set for the application offsets and not for the start of the flash memory.

If you use CanBoot to load Klipper it knows to offset the Klipper code correctly.

18

hi,

I’ll try later

But I see another possibility…, it occurred to me tonight.

I have an EBB42 that works through CANBUS… with outdated firmware, the problem is that I can’t get the new EBB42 to work.

You could “extract” the EBB42 firmware that works for:

A-Backup
B- Record them on the new EBB42

Do you see it possible?

How could it be done?

19

What would happen, if you just followed the advice given by the experienced users like @NAPCAL and stop messing around?

1 Like