Flashing over CAN not working with Big Tree Tech EBB36 v1.2 from BTT U2C v2.1 #44
Comments
|
Same for me but using a Huvud 6.1 board. Term resistors are reading 60 Ohms and connection seems fine since it gets UUID. pi@voron:~/klipper/lib/canboot $ python3 flash_can.py -i can0 -f |
|
Chime in if you are using a U2C, and if so, what version, V1-STM32F072 or V2-STM32G0B1 I have the STM32F072 without this issue, but I do know of another user that has the STM32G0B1 that has this issue. |
|
BTT U2C v2.1 (STM32G0B1) |
|
U2C v2.1 with EBB42 v 1.2 both G0B1 chips. Flashed over DFU and seams to be working. Had to send cmd's |
|
For the people having issues, can you try and follow this guide with all the exact settings? https://maz0r.github.io/klipper_canbus/toolhead/ebb36-42_v1.1.html I was trying to reproduce the issue and it actually worked on hardware that didn't work before. |
|
I tried both 500000 and 250000, followed the guide verbatim. Tried different offsets etc. Nothing worked. |
|
I'm giving up on the Canbus mod. Way more trouble than it saves in wiring. Huvud board is too big to fit anywhere on a Stealthburner anyway. Disappointing waste of $ |
Robert, if you don't mind, are you trying to use the BTT U2C? If so, please comment with the STM32 version on yours; thanks. |
|
I am using a Huvud 6.1 board with an STM32F103C8T6. Latest version w
CANBOOT pre installed. CAN interface is a Waveshare RS485 CAN Hat w a RasPi4.
Did not have an ST-Link to try re-flashing the CAN bootloader and I have
decided to quit screwing with it and just go with direct wires.
|
|
So I think I managed to track the issue down to something with possibly the Pi4 (or my specific Pi4). I'm basically at the point where I can replace my Pi4 with a Pi3 (only changing the Pi, keeping same SD card and everything else connected) and make it work. Don't think there is any issue with my Pi4 as everything else is stable, but I plan on trying to swap that with another and keep testing. UPDATE: Tried another Pi4 and same issue. Not sure if it helps anyone but here is the full error when it fails on my Pi4:
|
|
In another issue post when the EBB's changed to STM32G0B1 when asking about CAN-FD that G0B1 provides and if we needed to upgrade our CAN bus devices to CAN-FD; Arksine responded that the CanBoot for the G0B1 would use the basic CAN bus protocol and not the FD protocol, so no update needed. Klipper seems to support both basic & FD on the G0B1. Still, the overall bus has to use the same protocol, so the newer U2C with the G0B1 is more than likely setting up for FD and will not fully talk to CanBoot in basic CAN mode, like binary file transfer of the Klipper firmware but can retrieve UUID's from devices running basic CAN. |
|
Alright my last update. Seems like this is some kind of interaction between the Pi4 and the BTT U2C v2.1. Since I have a Octopus Pro, I ended up just using the onboard can bridge and I don't have anymore issues with the same can toolhead. |
|
I'm also experiencing this issue - canboot and klipper are both flashed via USB, and klipper is working, but attempting to flash over CAN corrupts something, and then you have to start over from scratch with DFU again. Running the U2C v2.1 and EBB36 v1.2 - both on G0B1 chips, and all connected to a CB1 mounted on a Manta MP8. Not sure if its related - but I also cannot use the ADXL on my EBB. The moment I enable that section of the klipper config, klipper fails to start. Kinda seems like anything high-bandwidth is having issues? Or maybe its unrelated. |
|
Same problem here with a Pi4 and an octopus 1.1
I can properly flash with the serial usb for the first klipper flash. But after klipper with can is flashed, I can no longer use the serial usb as only the can0 interface is available. Also note that doing a power cycle put everything back in working condition. |
|
Some complementary info :
It is the octopus 1.1 board itself that I'm trying to update, not the toolhead. |
|
After some more test, I get the following. While the flash fail, it appear that the board itself restart and start on the bootloader itself. The board is now available as a serial usb device and can be flashed with The board restart immediately on klipper with the can0 interface working. |
|
The issue called out is issues flashing the EBB42 with CanBoot. Flashing the Octopus (when using it as a CAN bus bridge, Klipper), you will not be able to do this because CanBoot doesn't support the CAN bus bridge mode. When trying to flash using CanBoot via CAN bus will not work because Klipper on the MCU will not be running; therefore, the CAN bus bridge will not be running. So you will always be required to use the USB to flash CanBoot or Klipper CAN bus bridge. If you were using a CAN hat or USB to CAN bus adapter, you would be able to flash over the CAN bus. |
|
Ok I though the problematic was the same, but as you said it's definitely something else. And you are probably right, since the octopus is in bridge mode. |
|
When having to flash via USB, CanBoot will have a different USB ID than Klipper. If you setup CanBoot with the quick double click of the reset to jump into firmware loading. Then quick double click the reset will get you into that mode. Then using the CanBoot USB ID, you can flash the Octopus with Klipper. I store my CanBoot ID in my printer.cfg as a comment for easy access. |
|
I was going to try to flash the U2C V2 (STM32G0B1) with Klipper in CAN bus bridge mode to see if this would correct the issue, but BTT is using (PB5 RX and PB6 TX), and these are not selectable CAN bus pins under Klipper. As I see it right now, it is a common issue with U2C V2 and CanBoot, there is no issues with the U2C V1's. |
Norbs12
changed the title
|
Confirming I had the same issue using G0B1_U2C_fw on my u2c v2.1 with ebb36 v1.2, the firmware transfer itself fails and then the canboot ebb becomes non responsive until I re program with cube programmer. issue not observed with U2C v1.1 |
|
I can confirm that the issue occurred with U2C 2.1 but not with the 1.0. I had the U2C 2.1 on two different printers, both with EBB36 1.2, and had issues with flashing and using canbus speeds above 250k. Switched both to U2C v1. 0 and was able to flash without issue and run 1MB canbus speed. |
|
It sounds like the STM32G0 variants of the U2C cant handle the somewhat larger transfers required to upload firmware...in fact it appears that these devices have general communications issues. There does appear to be a fork of CandleLight for the G0. If someone is feeling adventurous you could try following these instructions to build and flash it to a U2C v2.1. |
I have a spare u2c v2.1 and ebb36 v1.2. I’ll try the above and report back |
|
I've tried the candlelight fork on a U2C 2.1 and it didn't help,. That fork hasn't been updated in 5 months. |
|
If candlelight doesn't work I added 100% untested support for pins PB5 and PB6 to Klipper here. You can add my fork as a Klipper remote and checkout the Note: I suspect that this would require adding the U2C V2.1 as an |
|
I think the issue is with the BTT U2C V2 firmware trying to use FDCAN for file transfers or not settling this up correctly since the rest of the bus is non-FD. It seems to be only with binary data transfers, all other communications works. |
I tried flashing the U2C 2.1 board with klipper in usb to can bridge using your fork. I could not get it to see anything on the can network. Since BTT has not published the code for the u2c 2.1 board, it makes it hard to see what they used / changed. I suspect that the U2C 2.1 board is using FDCAN which is causing the transfer issues that NAPCAL mentioned. |
|
I seem to be having the same issue with the U2C 2.1 and EBB42 v1.1. Was going to send back my EBB thinking it was bad (got it already opened from amazon) but if I'm reading the comments right it is a problem with the U2C, is that correct? My PI4 recognizes everything all the way up to flashing Klipper then I get the following error. After I get 0 UUIDs found until I reinstall canboot. `pi@fluiddpi:~/klipper $ python3 ~/CanBoot/scripts/flash_can.py -i can0 -f ~/klipper/out/klipper.bin -u 793da0714a5e [####ERROR:root:Can Read Error During handling of the above exception, another exception occurred: Traceback (most recent call last): The above exception was the direct cause of the following exception: Traceback (most recent call last): During handling of the above exception, another exception occurred: Traceback (most recent call last): The above exception was the direct cause of the following exception: Traceback (most recent call last): During handling of the above exception, another exception occurred: Traceback (most recent call last): The above exception was the direct cause of the following exception: Traceback (most recent call last): During handling of the above exception, another exception occurred: Traceback (most recent call last): The above exception was the direct cause of the following exception: Traceback (most recent call last): During handling of the above exception, another exception occurred: Traceback (most recent call last): The above exception was the direct cause of the following exception: Traceback (most recent call last): During handling of the above exception, another exception occurred: Traceback (most recent call last): The above exception was the direct cause of the following exception: Traceback (most recent call last): During handling of the above exception, another exception occurred: Traceback (most recent call last): The above exception was the direct cause of the following exception: Traceback (most recent call last): During handling of the above exception, another exception occurred: Traceback (most recent call last): The above exception was the direct cause of the following exception: Traceback (most recent call last): During handling of the above exception, another exception occurred: Traceback (most recent call last): The above exception was the direct cause of the following exception: Traceback (most recent call last): During handling of the above exception, another exception occurred: Traceback (most recent call last): |
|
@garrettwp revise step 6 (see below); the U2C’s don’t have a reset button; it is a boot button.
Press and hold the boot button on the u2c and plug the usb cable back in, then release the boot button. |
|
Thanks for the catch! I have updated it. |
|
confirming this worked. flashed u2c with attached firmware per directions. everything is up |
|
@bigtreetech, can you supply any details about what was changed in the supplied firmware? Perhaps a link to the source? |
|
@bigtreetech confirmed working and am able to flash two different ebb36 1.2 over can with a U2C2.1 Thank you! |
|
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: I had previously flashed CanBoot using Edit: my device shows three alternatives when in dfu mode: |
|
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 |
|
Here are instructions that were adapted from some previously posted on discord to build and use make flash. sudo apt-get install cmake gcc-arm-none-eabi git after this, plug a usb-c cable to the rpi. make flash-G0B1_U2C_fw disconnect the usb cable from the u2c and reconnect. it should now be working. |
@e2p2 did you use this altered code provided by BigTreeTech? I only ask because the link you provided doesn't match BTT's. |
|
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. |
|
@e2p2 thanks for sharing the instructions. Broadly this is what I had already tried (checking out and building the Edit: just to confirm - I am in the branch and can't see either of those U2C build targets: |
|
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? |
|
@e2p2 BigTreeTech posted 3d ago
BigTreeTech commented 2d 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. |
|
@e2p2 Try this sudo apt-get install gcc-arm-none-eabi mkdir build make budgetcan_fw budgetcan is the board type name that BTT has added for the G0B1. |
|
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. |
|
Interestingly using the budgetcan_fw does seem to have improved things, I'm no longer getting errors running 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? |
|
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 after this, plug a usb-c cable to the rpi. make flash-budgetcan_fw disconnect the usb cable from the u2c and reconnect. it should now be working. |
|
Two back to back prints with no issues. Seems very stable |
|
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! |
|
FYI looks like @bigtreetech have broken their repo again: 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 |
|
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? |
|
Yes, that is the correct one for U2C with a G0B1 STM, don't use if yours is a F072 STM. |
|
Thank you - update went through - I still have yet to connect the SB2209 though...:-) |
|
Does anybody get the error ` sudo dfu-util -a 0 -D U2C_V2_STM32G0B1.bin --dfuse-address 0x08000000:force:mass-erase:leave -d 0483:df11 Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc. dfu-util: Invalid DFU suffix signature |
|
The last firmware that I know that worked is this one. G0B1_U2C_V2 To get the U2C into DFU mode.
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 UPD: Change the TRSYNC_TIMEOUT = 0.05 in the klippy/mcu.py helped to fix the timeout during homing. |
|
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. |
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:
#44 (comment)
--------- 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.
The text was updated successfully, but these errors were encountered: