Flashing over CAN not working with Big Tree Tech EBB36 v1.2 from BTT U2C v2.1

Norbs12 commented 1 year ago

EDIT: This turned out to be a issue with the BTT U2C v2.1, a new firmware was released which addresses this issue. I'm closing this out. Here is the link to the firmware which was posted by BTT below.

Firmware link: https://github.com/Arksine/CanBoot/files/10410265/G0B1_U2C_V2.zip

Comment from BTT that solved this: https://github.com/Arksine/CanBoot/issues/44#issuecomment-1381555466

--------- Original post below ---------

Currently you can flash CanBoot onto the device and it's recognized over the CAN network, but then trying to flash Klipper, it ends with a bunch of errors during the flash and requires reflash in DFU mode.

I will try to get more details on the errors soon, when this first happened I thought I was just doing somethign wrong but others are also seeing this issue. Just wanted this as a placeholder for now and for awareness.

The board otherwise functions over CAN reliably if flashed with only Klipper via DFU.

Others who also experienced this: https://www.youtube.com/watch?v=Ucq3U-H2N-A

EDIT: Seems to be an issue specifically with the BTT U2C v2.1, I was able to use Octopus Pro can bridge without issue.

bigtreetech commented 1 year ago

@bigtreetech, can you supply any details about what was changed in the supplied firmware? Perhaps a link to the source?

The main frequency of mcu is set to 64Mhz
disable USB bulk_doublebuffer_enable The source file is here. https://github.com/bigtreetech/candleLight_fw/commits/stm32g0_support

lakai commented 1 year ago

G0B1_U2C_V2.zip

For users who encounter the canboot programming problem of U2C V2 version , please update the firmware of U2C V2 to this file for testing. This file is a compressed file. After decompression, there will be a .bin binary file, which can be directly programed to U2C V2 by DFU

@Rick88Stang Hello. can you test this?

@bigtreetech confirmed working and am able to flash two different ebb36 1.2 over can with a U2C2.1

Thank you!

fredkelly commented 1 year ago

Sorry to reopen this thread- this has been by far the most helpful on getting my U2C v2.1 working. I have tried the attached G0B1_U2C_V2.zip but get an error when using the suggested command to flash:

pi@fluiddpi-ender5:~ $ sudo dfu-util -D G0B1_U2C_V2.bin -d 0483:df11 -a 0 -s 0x08000000:leave
[sudo] password for pi:
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: File too short for DFU suffix
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuDNLOAD-IDLE, status = 0
aborting previous incomplete transfer
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash   "
Downloading to address = 0x08000000, size = 0
dfu-util: Last page at 0x07ffffff is not writeable

I had previously flashed CanBoot using dfu-util without issue so I'm not sure if this is me or the file itself?

Edit: my device shows three alternatives when in dfu mode:

pi@fluiddpi-ender5:~ $ dfu-util -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Found DFU: [0483:df11] ver=0200, devnum=2, cfg=1, intf=0, path="1-1", alt=2, name="@Internal Flash   /0x08000000/64*02Kg", serial="2042394D5542"
Found DFU: [0483:df11] ver=0200, devnum=2, cfg=1, intf=0, path="1-1", alt=1, name="@Internal Flash   /0x08000000/64*02Kg", serial="2042394D5542"
Found DFU: [0483:df11] ver=0200, devnum=2, cfg=1, intf=0, path="1-1", alt=0, name="@Internal Flash   /0x08000000/64*02Kg", serial="2042394D5542"

NAPCAL commented 1 year ago

Try this command:

sudo dfu-util -a 0 -D G0B1_U2C_V2.bin --dfuse-address 0x08000000:force:mass-erase:leave -d 0483:df11

Also, if you want to upgrade your dfu-util from 0.9 to 0.11 do the following:

git clone git://git.code.sf.net/p/dfu-util/dfu-util cd dfu-util sudo ./autogen.sh sudo ./configure sudo make sudo make install

e2p2 commented 1 year ago

Here are instructions that were adapted from some previously posted on discord to build and use make flash. This is using the referenced github that BTT posted.

sudo apt-get install cmake gcc-arm-none-eabi git cd ~ # if you have a previously downloaded a differet candlelight_fw repo you will need to first do "rm -r candleLight_fw" git clone https://github.com/bigtreetech/candleLight_fw cd candleLight_fw git checkout stm32g0_support mkdir build cd build cmake .. -DCMAKE_TOOLCHAIN_FILE=../cmake/gcc-arm-none-eabi-8-2019-q3-update.cmake make G0B1_U2C_fw

after this, plug a usb-c cable to the rpi. enter dfu mode: while pressing the BOOT button of the u2c connect the usb-c cable.

make flash-G0B1_U2C_fw

disconnect the usb cable from the u2c and reconnect. it should now be working.

NAPCAL commented 1 year ago

@bigtreetech, can you supply any details about what was changed in the supplied firmware? Perhaps a link to the source?

The main frequency of mcu is set to 64Mhz

disable USB bulk_doublebuffer_enable

The source file is here.

https://github.com/bigtreetech/candleLight_fw/commits/stm32g0_support

@e2p2 did you use this altered code provided by BigTreeTech? I only ask because the link you provided doesn't match BTT's.

e2p2 commented 1 year ago

I'll freely admit my knowledge of github is Google based. As I understand it to access a branch you have to connect to the primary repo then checkout the needed commit branch. So the git clone is for https://github.com/bigtreetech/candleLight_fw then the git checkout stm32g0_support switches to the appropriate branch.

fredkelly commented 1 year ago

@e2p2 thanks for sharing the instructions. Broadly this is what I had already tried (checking out and building the stm32g0_support branch. I however ran make candleLight_fw and make flash-candleLight_fw. I tried using your instruction but found that wasn't recognised - am I missing something?

pi@fluiddpi-ender5:~/candleLight_fw/build $ make G0B1_U2C_fw
make: *** No rule to make target 'G0B1_U2C_fw'.  Stop.

Edit: just to confirm - I am in the branch and can't see either of those U2C build targets:

pi@fluiddpi-ender5:~/candleLight_fw/build $ git status
On branch stm32g0_support
Your branch is up to date with 'origin/stm32g0_support'.

nothing to commit, working tree clean
pi@fluiddpi-ender5:~/candleLight_fw/build $ make flash-G0B1_U2C_fw
make: *** No rule to make target 'flash-G0B1_U2C_fw'.  Stop.

e2p2 commented 1 year ago

This did work before BTT made their latest updates to the branch. I used these commands in December to build the G0B1 bin and the build process worked. My mistake for not testing it and assuming the previous commands would work. Digging through the code it appears the only target left that uses the G0B1 chip is called budgetcan_fw. @bigtreetech, can you please provide the correct process to build (and flash) G0B1_U2C_V2.bin using the referenced branch?

NAPCAL commented 1 year ago

@e2p2 BigTreeTech posted 3d ago

G0B1_U2C_V2.zip

For users who encounter the canboot programming problem of U2C V2 version , please update the firmware of U2C V2 to this file for testing. This file is a compressed file. After decompression, there will be a .bin binary file, which can be directly programed to U2C V2 by DFU

BigTreeTech commented 2d ago

The main frequency of mcu is set to 64Mhz

disable USB bulk_doublebuffer_enable

The source file is here.

https://github.com/bigtreetech/candleLight_fw/commits/stm32g0_support

e2p2 commented 1 year ago

@NAPCAL, That is just the commits page showing the change log. Until BTT provides the correct build process we have no choice but to use the provided BIN file.

NAPCAL commented 1 year ago

@e2p2 Try this git clone -b stm32g0_support --single-branch https://github.com/bigtreetech/candleLight_fw.git

sudo apt-get install gcc-arm-none-eabi

mkdir build cd build cmake .. -DCMAKE_TOOLCHAIN_FILE=../cmake/gcc-arm-none-eabi-8-2019-q3-update.cmake

make budgetcan_fw

budgetcan is the board type name that BTT has added for the G0B1.

e2p2 commented 1 year ago

My previous commands would work as well substituting "make budgetcan_fw" for "make G0B1_U2C_fw" and "make flash-budgetcan_fw" for "make flash-G0B1_U2C_fw". I am just not certain that budgetcan_fw is the U2C v2. Budgetcan_fw does use the G0B1 chip but it may not be the correct device.

fredkelly commented 1 year ago

Interestingly using the budgetcan_fw does seem to have improved things, I'm no longer getting errors running canbus_query.py and also dfu-util -l shows a device detected (not in DFU mode):

pi@fluiddpi-ender5:~ $ dfu-util -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Cannot open DFU device 1d50:606f
pi@fluiddpi-ender5:~ $ ~/klippy-env/bin/python ~/klipper/scripts/canbus_query.py can0
Total 0 uuids found

I need to test further but have to head out, will report back later. Incidentally, I didn't mention in my original post but my U2C has a blue light constantly illuminated. All the tutorials state that the blue light should only be on in DFU mode - is this a v2.1 thing or perhaps a sign of faulty hardware?

e2p2 commented 1 year ago

Using "make budgetcan_fw" and "make flash-budgetcan_fw" I was able to build working firmware for and flash firmware to the U2C v2.1. I was then able to run my firmware update script to update klipper for the controller board and then the EBB over canbus with no errors. I would still appreciate @bigtreetech chiming in to confirm this is correct. I will try some print jobs to make sure canbus communication is stable. Here is the update build commands so they are in one place...

sudo apt-get install cmake gcc-arm-none-eabi git cd ~ # if you have a previously downloaded a differet candlelight_fw repo you will need to first do "rm -r candleLight_fw" git clone https://github.com/bigtreetech/candleLight_fw cd candleLight_fw git checkout stm32g0_support mkdir build cd build cmake .. -DCMAKE_TOOLCHAIN_FILE=../cmake/gcc-arm-none-eabi-8-2019-q3-update.cmake make budgetcan_fw

after this, plug a usb-c cable to the rpi. enter dfu mode: while pressing the BOOT button of the u2c connect the usb-c cable.

make flash-budgetcan_fw

disconnect the usb cable from the u2c and reconnect. it should now be working.

e2p2 commented 1 year ago

Two back to back prints with no issues. Seems very stable

fredkelly commented 1 year ago

Awesome. I managed to get my communication up and running using this (though flashing Klipper to the EBB via the U2C took a few attempts). Seems to be functioning okay now but I need to re-assemble the printer and run some test prints.

Many thanks for all the help here!

sammcj commented 1 year ago

FYI looks like @bigtreetech have broken their repo again:

build <stm32g0_support>:# make budgetcan_fw                                                                                                                                             
make: *** No rule to make target 'budgetcan_fw'.  Stop.

I have found this fork + branch combo that seems to work - though it does show up 2 can interfaces which is interesting:

https://github.com/marckleinebudde/candleLight_fw/tree/multichannel

[Fri Apr 21 19:16:39 2023] usb 1-1.1: new full-speed USB device number 21 using ehci-platform
[Fri Apr 21 19:16:40 2023] usb 1-1.1: New USB device found, idVendor=0483, idProduct=df11, bcdDevice= 2.00
[Fri Apr 21 19:16:40 2023] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Fri Apr 21 19:16:40 2023] usb 1-1.1: Product: DFU in FS Mode
[Fri Apr 21 19:16:40 2023] usb 1-1.1: Manufacturer: STMicroelectronics
[Fri Apr 21 19:16:40 2023] usb 1-1.1: SerialNumber: 207B32535841
[Fri Apr 21 19:16:47 2023] usb 1-1.1: reset full-speed USB device number 21 using ehci-platform
[Fri Apr 21 19:16:49 2023] usb 1-1.1: USB disconnect, device number 21
[Fri Apr 21 19:16:52 2023] usb 1-1.1: new full-speed USB device number 22 using ehci-platform
[Fri Apr 21 19:16:52 2023] usb 1-1.1: New USB device found, idVendor=1d50, idProduct=606f, bcdDevice= 0.00
[Fri Apr 21 19:16:52 2023] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Fri Apr 21 19:16:52 2023] usb 1-1.1: Product: budgetcan gs_usb
[Fri Apr 21 19:16:52 2023] usb 1-1.1: Manufacturer: budgetcan
[Fri Apr 21 19:16:52 2023] usb 1-1.1: SerialNumber: 004400205841500C20373233
[Fri Apr 21 19:16:52 2023] gs_usb 1-1.1:1.0: Configuring for 2 interfaces
[Fri Apr 21 19:16:53 2023] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready

8: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP group default qlen 1024
    link/can
9: can1: <NOARP,ECHO> mtu 16 qdisc noop state DOWN group default qlen 10
    link/can

stahlfabrik commented 1 year ago

Hmmm. Why is the bin in the zip file above from Bigtreetech 130kB in size. While on their GitHub there seems to be a firmware file that ist just 20kB in size.

https://github.com/bigtreetech/U2C/blob/master/firmware/U2C_V2_STM32G0B1.bin

The git history even says: "update U2C V2 G0B1 firmware, fix Canboot error" so it should be the correct file, right?

@bigtreetech What is the correct file to update the V2.1 today?

NAPCAL commented 1 year ago

Yes, that is the correct one for U2C with a G0B1 STM, don't use if yours is a F072 STM.

stahlfabrik commented 1 year ago

Thank you - update went through - I still have yet to connect the SB2209 though...:-)

FlySpot commented 5 months ago

Does anybody get the error dfu-util: Last page at 0x0806c5d1 is not writeable with flashing last BTT firmware to the BTT U2C board? I have board on the STM32G0B1 and the file https://github.com/bigtreetech/U2C/blob/master/firmware/U2C_V2_STM32G0B1.bin is over 407kB size. Oposit of it the firmware from the https://github.com/Esoterical/voron_canbus/tree/main/can_adapter/BigTreeTech%20U2C%20v2.1 has only 127kB and it can be successfully uploaded but in result it gives me 'bytes_invalid' during homing. Can somebody suggest how to flash the firmware from BTT to the U2C? Thanks a lot in advance.

` sudo dfu-util -a 0 -D U2C_V2_STM32G0B1.bin --dfuse-address 0x08000000:force:mass-erase:leave -d 0483:df11 dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc. Copyright 2010-2016 Tormod Volden and Stefan Schmidt This program is Free Software and has ABSOLUTELY NO WARRANTY Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Invalid DFU suffix signature dfu-util: A valid DFU suffix will be required in a future dfu-util release!!! Opening DFU capable USB device... ID 0483:df11 Run-time device DFU version 011a Claiming USB DFU Interface... Setting Alternate Setting #0 ... Determining device status: state = dfuDNLOAD-IDLE, status = 0 aborting previous incomplete transfer Determining device status: state = dfuIDLE, status = 0 dfuIDLE, continuing DFU mode device DFU version 011a Device returned transfer size 1024 DfuSe interface name: "Internal Flash " Performing mass erase, this can take a moment Downloading to address = 0x08000000, size = 443858 dfu-util: Last page at 0x0806c5d1 is not writeable`

NAPCAL commented 5 months ago

The last firmware that I know that worked is this one. G0B1_U2C_V2 Extract the .bin file and transfer it to your home directory on the RPi or clone.

To get the U2C into DFU mode.

Unplug the U2C from all connections, including the USBC.
Ensure the USBA of the USBC cable is plugged into your RPi or clone.
While holding down the boot button, plug in the USBC cable.
Release the boot button.
Check if your RPi or clone sees the U2C in DFU mode by entering the command lsusb
Look for STM and DFU in the output on the same line; if not, try again putting the U2C in DFU mode.
copy this command and paste it into your ssh terminal

sudo dfu-util -a 0 -D ~/G0B1_U2C_V2.bin --dfuse-address 0x08000000:force:mass-erase -d 0483:df11

If successful, disconnect the USBC cable from the U2C, then reconnect it.

Note: the U2C is not a Klipper device, so it will not appear as a serial device. It will only show via the lsusb command as 'OpenMoko, Inc. Geschwister Schneider CAN adapter'

If you see that in the output, it is connected and operational.

Check with network command to see if can0 is up and running; if not, you need to make sure to follow one of my CAN guides.

FlySpot commented 5 months ago

The last firmware that I know that worked is this one. G0B1_U2C_V2 Extract the .bin file and transfer it to your home directory on the RPi or clone.

To get the U2C into DFU mode.

Unplug the U2C from all connections, including the USBC.

Ensure the USBA of the USBC cable is plugged into your RPi or clone.

While holding down the boot button, plug in the USBC cable.

Release the boot button.

Check if your RPi or clone sees the U2C in DFU mode by entering the command lsusb

Look for STM and DFU in the output on the same line; if not, try again putting the U2C in DFU mode.

copy this command and paste it into your ssh terminal

sudo dfu-util -a 0 -D ~/G0B1_U2C_V2.bin --dfuse-address 0x08000000:force:mass-erase -d 0483:df11

If successful, disconnect the USBC cable from the U2C, then reconnect it.

Note: the U2C is not a Klipper device, so it will not appear as a serial device. It will only show via the lsusb command as 'OpenMoko, Inc. Geschwister Schneider CAN adapter'

If you see that in the output, it is connected and operational.

Check with network command to see if can0 is up and running; if not, you need to make sure to follow one of my CAN guides.

Thanks NAPCAL it successfully flashed but still have issue Communication timeout during homing x it works for Y axis but not for the X.

UPD: Change the TRSYNC_TIMEOUT = 0.05 in the klippy/mcu.py helped to fix the timeout during homing.

NAPCAL commented 5 months ago

Check the 24V power at the EBB connector with a meter to see if it stays stable during homing, and string some wires just temporarily for the meter.

Also, with the power off check the CAN bus wiring during movement like it was homing.

Use this table to check for each failure condition.

CAN-bus-phyical-layer-debug

Arksine / katapult

Flashing over CAN not working with Big Tree Tech EBB36 v1.2 from BTT U2C v2.1 #44