Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Serial Flashing broken: Error sending command [SEND_BLOCK] to Can Device #128

Open
DrKlipper opened this issue Sep 3, 2024 · 22 comments
Open

Comments

@DrKlipper
Copy link

Hi!

Just tried to flash a Manta M8P (V2.0) with Katapult / Klipper. It uses a STM32H723 controller.

Compiling and flashing Katapult was no big deal. And since I enabled the Status LED I can see that Katapult is running.
But problems start rising when I try to install Klipper:

biqu@bigtreetech-cb2:~/klipper$ make -j4 flash FLASH_DEVICE=/dev/ttyACM0
  Creating symbolic link out/board
  Building out/autoconf.h
  Building hid-flash
make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.
gcc -c -Wall -std=gnu99 -I . `pkg-config libusb-1.0 --cflags` main.c -o main.o
  Compiling out/src/sched.o
  Compiling out/src/command.o
  Compiling out/src/basecmd.o
gcc -c -Wall -std=gnu99 -I . `pkg-config libusb-1.0 --cflags` hid-libusb.c -o hid-libusb.o
  Compiling out/src/debugcmds.o
  Compiling out/src/initial_pins.o
  Compiling out/src/gpiocmds.o
  Compiling out/src/stepper.o
  Compiling out/src/endstop.o
gcc -c -Wall -std=gnu99 -I . `pkg-config libusb-1.0 --cflags` rs232.c -o rs232.o
gcc -no-pie main.o hid-libusb.o rs232.o `pkg-config libusb-1.0 --libs` -lrt -lpthread -o hid-flash
  Compiling out/src/trsync.o
  Compiling out/src/adccmds.o
  Compiling out/src/spicmds.o
  Compiling out/src/i2ccmds.o
  Compiling out/src/pwmcmds.o
  Compiling out/src/buttons.o
  Compiling out/src/tmcuart.o
  Compiling out/src/neopixel.o
  Compiling out/src/pulse_counter.o
  Compiling out/src/lcd_st7920.o
  Compiling out/src/lcd_hd44780.o
  Compiling out/src/spi_software.o
  Compiling out/src/i2c_software.o
  Compiling out/src/thermocouple.o
  Compiling out/src/sensor_adxl345.o
  Compiling out/src/sensor_angle.o
  Compiling out/src/sensor_mpu9250.o
  Compiling out/src/sensor_lis2dw.o
  Compiling out/src/sensor_ldc1612.o
  Compiling out/src/sensor_bulk.o
  Compiling out/src/stm32/watchdog.o
  Compiling out/src/stm32/gpio.o
  Compiling out/src/stm32/clockline.o
  Compiling out/src/stm32/dfu_reboot.o
  Compiling out/src/generic/crc16_ccitt.o
  Compiling out/src/generic/armcm_boot.o
  Compiling out/src/generic/armcm_irq.o
  Compiling out/src/generic/armcm_reset.o
  Compiling out/src/../lib/stm32h7/system_stm32h7xx.o
  Compiling out/src/stm32/stm32h7.o
  Compiling out/src/generic/armcm_timer.o
  Compiling out/src/stm32/gpioperiph.o
  Compiling out/src/stm32/stm32h7_adc.o
  Compiling out/src/stm32/stm32f0_i2c.o
  Compiling out/src/stm32/stm32h7_spi.o
  Compiling out/src/stm32/usbotg.o
  Compiling out/src/generic/canserial.o
  Compiling out/src/../lib/fast-hash/fasthash.o
  Compiling out/src/stm32/fdcan.o
  Compiling out/src/stm32/chipid.o
  Compiling out/src/generic/usb_canbus.o
  Compiling out/src/stm32/hard_pwm.o
  Preprocessing out/src/generic/armcm_link.ld
  Building out/compile_time_request.o
Version: v0.12.0-249-ga19d64feb
  Linking out/klipper.elf
  Creating hex file out/klipper.bin
  Flashing out/klipper.bin to /dev/ttyACM0
Entering bootloader on /dev/ttyACM0
Device reconnect on /sys/devices/platform/usbdrd/fcc00000.dwc3/xhci-hcd.4.auto/usb5/5-1/5-1.4/5-1.4:1.0
/usr/bin/python3 lib/canboot/flash_can.py -d /dev/serial/by-path/platform-xhci-hcd.4.auto-usb-0:1.4:1.0 -f out/klipper.bin

Attempting to connect to bootloader
CanBoot Connected
Protocol Version: 1.1.0
Block Size: 64 bytes
Application Start: 0x8020000
MCU type: stm32h723xxv0.0.1-70-g42909f8
Flashing '/home/biqu/klipper/out/klipper.bin'...

[ERROR:root:Can Flash Error
Traceback (most recent call last):
  File "/home/biqu/klipper/lib/canboot/flash_can.py", line 610, in main
    loop.run_until_complete(sock.run(args.device, args.baud, fpath))
  File "/usr/lib/python3.9/asyncio/base_events.py", line 642, in run_until_complete
    return future.result()
  File "/home/biqu/klipper/lib/canboot/flash_can.py", line 537, in run
    await flasher.send_file()
  File "/home/biqu/klipper/lib/canboot/flash_can.py", line 207, in send_file
    resp = await self.send_command('SEND_BLOCK', prefix + buf)
  File "/home/biqu/klipper/lib/canboot/flash_can.py", line 186, in send_command
    raise FlashCanError("Error sending command [%s] to Can Device"
FlashCanError: Error sending command [SEND_BLOCK] to Can Device
Error running flash_can.py
make: *** [src/stm32/Makefile:111: flash] Error 255

It seems that a lot of other people struggle with the same error.

So I tried an old Katapult version from February:
git checkout 3e23332

Flashing Katapult again followed by Klipper results in a running system. No more SEND_BLOCK Errors.

So there must be any change in the last 7 month which results in a non working Katapult version.
Btw ... I flashed klipper over the serial Katapult connection.

regards
Dominik

@Arksine
Copy link
Owner

Arksine commented Sep 3, 2024

Try flashing with flashtool.py in the Katapult repo rather than using make flash in Klipper. It may be that the script in the Klipper repo needs to be updated.

FWIW, I can't reproduce on a BTT Kraken, which is also an STM32H723 based device.

@DrKlipper
Copy link
Author

Try flashing with flashtool.py in the Katapult repo rather than using make flash in Klipper.

Did not work for me:

biqu@bigtreetech-cb2:~/katapult/scripts$ ./flashtool.py -d /dev/ttyACM0 -f ~/klipper/out/klipper.bin
Flashing Serial Device /dev/ttyACM0, baud 250000
Attempting to connect to bootloader
Katapult Connected
Software Version: v0.0.1-70-g42909f8
Protocol Version: 1.1.0
Block Size: 64 bytes
Application Start: 0x8020000
MCU type: stm32h723xx
Flashing '/home/biqu/klipper/out/klipper.bin'...

[ERROR:root:Flash Error
Traceback (most recent call last):
  File "/home/biqu/katapult/scripts/./flashtool.py", line 643, in main
    loop.run_until_complete(sock.run(args.device, args.baud, fpath))
  File "/usr/lib/python3.9/asyncio/base_events.py", line 642, in run_until_complete
    return future.result()
  File "/home/biqu/katapult/scripts/./flashtool.py", line 563, in run
    await flasher.send_file()
  File "/home/biqu/katapult/scripts/./flashtool.py", line 225, in send_file
    resp = await self.send_command('SEND_BLOCK', prefix + buf)
  File "/home/biqu/katapult/scripts/./flashtool.py", line 205, in send_command
    raise FlashError("Error sending command [%s] to Device" % (cmdname))
FlashError: Error sending command [SEND_BLOCK] to Device

Revision Katapult : 42909f8 (HEAD -> master, origin/master, origin/HEAD) stm32: dfu-util "make flash" rules for stm32 mcu
Revision Klipper : 08a1c9f12 (HEAD -> master, origin/master, origin/HEAD) docs: update temperature_probe documentation

So both should be up-to-date.

Dominik

@NAPCAL
Copy link

NAPCAL commented Sep 3, 2024

@DrKlipper do you have the latest Katapult & Python serial code installed on your RPi?

@DrKlipper
Copy link
Author

@DrKlipper do you have the latest Katapult & Python serial code installed on your RPi?

I installed pyserial with this command:
/usr/bin/python3 -m pip install pyserial

Katapult was the latest revision as shown above.

@dmcguire80
Copy link

dmcguire80 commented Sep 4, 2024

I've been having the same issue for awhile now.

biqu@BTT-CB1:~$ /usr/bin/python3 -m pip install pyserial Requirement already satisfied: pyserial in ./.local/lib/python3.9/site-packages (3.5)

Same error using the python3 flashtool.py -i can0 -q or python3 flash_can.py -i can0 -q

ERROR:root:Flash Error
Traceback (most recent call last):
  File "/home/biqu/Katapult/scripts/flashtool.py", line 499, in run_query
    self.cansock.bind((intf,))
OSError: [Errno 19] No such device

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/biqu/Katapult/scripts/flashtool.py", line 627, in main
    loop.run_until_complete(sock.run_query(intf))
  File "/usr/lib/python3.9/asyncio/base_events.py", line 642, in run_until_complete
    return future.result()
  File "/home/biqu/Katapult/scripts/flashtool.py", line 501, in run_query
    raise FlashError("Unable to bind socket to can0")
FlashError: Unable to bind socket to can0

@DrKlipper
Copy link
Author

Just tried this on a Raspberry Pi 5 with a new Fysetc Spider H7 board (STM32H723).
And it works even with the latest versions of Klipper / Katapult.

So it seems that there is a problem with the BTT Image for CB1/CB2 SBCs ...
Any idea how I can debug this stuff? Anything I could check to find the root cause of this problem?

@Arksine
Copy link
Owner

Arksine commented Sep 4, 2024

So it seems that there is a problem with the BTT Image for CB1/CB2 SBCs ...
Any idea how I can debug this stuff? Anything I could check to find the root cause of this problem?

When running flashtool.py on the device you are trying to debug, add the -v option to the command line for verbose output.

Try building the Katapult binary on your Pi 5, then copy it to the Manta and flash it. This will tell us if there is a problem with the build on the CB1/2/etc. If it still doesn't work then its likely related to a Kernel issue.

In addition, I have an pushed updated version of flashtool.py that increases the response timeout to 5 seconds, in the event there is some kind of delay in unlocking the flash.

@Arksine
Copy link
Owner

Arksine commented Sep 4, 2024

I've been having the same issue for awhile now.

You have a different issue. You are attempting to flash over CANBUS rather than USB and the CAN interface is not available. I would suggest asking for assistance in how to install/setup your USB to CAN device on the Klipper Discord or Discourse.

@DrKlipper
Copy link
Author

Try building the Katapult binary on your Pi 5, then copy it to the Manta and flash it.

Building Katapult on the Pi5 results in a working version.
I can flash on the CB2 with no errors.

In addition, I have an pushed updated version of flashtool.py that increases the response timeout to 5 seconds, in the event there is some kind of delay in unlocking the flash.

Tried this before with Katapult compiled on the CB2 ... Did not work.

@DrKlipper
Copy link
Author

One addition ...
As I said in my initial post ... When I use Katapult git revision 3e23332 it works on the CM2, too.
So there must be any change in some of the latest releases.

@Arksine
Copy link
Owner

Arksine commented Sep 4, 2024

Building Katapult on the Pi5 results in a working version.
I can flash on the CB2 with no errors.

What is the output from the following command on the CB2?

arm-none-eabi-gcc --version

Tried this before with Katapult compiled on the CB2 ... Did not work.

I pushed the updated flashtool.py an hour ago.

As I said in my initial post ... When I use Katapult git revision 3e23332 it works on the CM2, too.
So there must be any change in some of the latest releases.

The Makefile was updated to support newer versions of gcc. Katapult's build is derived from Klipper, and this change is keeping in sync with it. Older versions should work. Once I know the version of gcc on your CB2 I'll see if I can reproduce.

@DrKlipper
Copy link
Author

arm-none-eabi-gcc --version

biqu@bigtreetech-cb2:~$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (15:8-2019-q3-1+b1) 8.3.1 20190703 (release) [gcc-8-branch revision 273027]
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I pushed the updated flashtool.py an hour ago.

I know. I tested with the latest version:

biqu@bigtreetech-cb2:~/katapult$ git log --oneline
10abb2a (HEAD -> master, origin/master, origin/HEAD) flashtool: increase default read timeout

Hope that was the correct version.

@Arksine
Copy link
Owner

Arksine commented Sep 4, 2024

arm-none-eabi-gcc (15:8-2019-q3-1+b1) 8.3.1 20190703 (release) [gcc-8-branch revision 273027]

This is a very old version of the gnu toolkit, and it looks like the package may be a beta. I can't think of any good reason for a recent linux distribution to ship with this toolkit.

I couldn't reproduce with an older release. I'm going to download the closest release and see if I can repro. This may be a situation where the Distribution Maintainer (BTT?) need to resolve the issue. I can't revert the Makefile changes, as its imperative that Katapult support the latest gcc release for Raspberry Pis and Desktop class PCs.

@DrKlipper
Copy link
Author

Ok I will ask my contact at BTT for that topic.
This whole image is to old to be honest ...
It´s bullseye and some simple tools like ncdu or wavemon can´t be found in the repo. Very strange.

So I think it is a workaround to use an older katapult revision for the moment.
Hope thy can update the image to a bookworm release with new packages ...

@Arksine
Copy link
Owner

Arksine commented Sep 4, 2024

FWIW, I was able to download the exact version of the gnu utils and the binary worked fine. Its possible that there is something wrong with the build provided in the repo. If the OS is aarch64 another potential workaround is to download a new version of the toolchain. If its 32-bit then the following instructions won't work.

https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads

You will specifically want the aarch64 toolchain with an aarch32 bare metal target.

Extract it, and you will find a bin folder containing the various toolchain binaries (ie: arm-none-eabi-gcc). You can then test it by temporarily prefixing the path to the bin folder to PATH:

export PATH=/path-to-bin-toolchain/bin:$PATH

Replace /path-to-toolchain/bin with the actual path. Then build Katapult and see if that binary works.

@DrKlipper
Copy link
Author

Getting a new version of the toolchain is a hassel. It results in a lot new errors because libs and includes are at the wrong place and / or missing. Would be a real pain to get this up and running by hand.
I will contact BTT tomorrow.

@AlatusAles
Copy link

Hi!
Host - Debian 12 (x64)
Octopus H723

image

image

juj@3DP:$ sudo service klipper stop
Failed to stop klipper.service: Unit klipper.service not loaded.
juj@3DP:
$ ls /dev/serial/by-id
usb-katapult_stm32h723xx_72300-if00
juj@3DP:~$ ~/katapult/scripts/flashtool.py -d /dev/serial/by-id/usb-katapult_stm32h723xx_72300-if00 -v
Flashing Serial Device /dev/serial/by-id/usb-katapult_stm32h723xx_72300-if00, baud 250000
Attempting to connect to bootloader
Katapult Connected
Software Version: v0.0.1-75-g90eb71b
Protocol Version: 1.1.0
Block Size: 64 bytes
Application Start: 0x8020000
MCU type: stm32h723xx
Flashing '/home/juj/klipper/out/klipper.bin'...

[INFO:root:Command 'SEND_BLOCK': Received NACK
INFO:root:Command 'SEND_BLOCK': Received NACK
INFO:root:Command 'SEND_BLOCK': Received NACK
INFO:root:Command 'SEND_BLOCK': Received NACK
INFO:root:Command 'SEND_BLOCK': Received NACK
ERROR:root:Flash Error
Traceback (most recent call last):
File "/home/juj/katapult/scripts/flashtool.py", line 678, in main
await sock.run(args.device, args.baud, fpath)
File "/home/juj/katapult/scripts/flashtool.py", line 625, in run
await flasher.send_file()
File "/home/juj/katapult/scripts/flashtool.py", line 237, in send_file
resp = await self.send_command('SEND_BLOCK', prefix + buf)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/juj/katapult/scripts/flashtool.py", line 216, in send_command
raise FlashError("Error sending command [%s] to Device" % (cmdname))
FlashError: Error sending command [SEND_BLOCK] to Device

Any ideas?

@AlatusAles
Copy link

Hi!
Debian 11 (x64) - solved the problem!

image

@ticso24
Copy link

ticso24 commented Dec 2, 2024

I am just facing the exact same problem with a CB1 on a Manta 8 with H723.

However, building katapult on a Pi3 vs. on the CB1 results in the same binary:

biqu@v2:~/katapult$ md5sum out/katapult.bin
6c54165e7f571a6f49952ecc523782d6 out/katapult.bin

pi@v2:~/katapult $ md5sum out/katapult.bin
6c54165e7f571a6f49952ecc523782d6 out/katapult.bin

The Pi3 is used on a recently installed printer with katapult used on a FYSETC spider board with an F446 controller, which
worked fine.

Settings for the Manta are the same as Dr. Klipper used, because I often use his webpage as reference, so that is with !PC3 and CAN bridge as well.

@Arksine
Copy link
Owner

Arksine commented Dec 2, 2024

However, building katapult on a Pi3 vs. on the CB1 results in the same binary:

What version of gcc is running on your Pi 3? You can check it with:

arm-none-eabi-gcc --version

@ticso24
Copy link

ticso24 commented Dec 2, 2024

pi@v2:~ $ arm-none-eabi-gcc --version
arm-none-eabi-gcc (15:8-2019-q3-1+b1) 8.3.1 20190703 (release) [gcc-8-branch revision 273027]

The printer with the Pi3 was based on a relative new mainsailOS pi image:
2024-01-20-MainsailOS-1.3.2-raspberry-rpi64.img

The CB1 has the same compiler version.
So both are the same old version Dr. Klipper reported.

No surprise the compiled binaries are identic.

@Arksine
Copy link
Owner

Arksine commented Dec 7, 2024

FWIW, I tried again to reproduce with a build on MainsailOS with a BTT Kraken and was unable to do so. The regression appears to primarily impact the Manta M8P with older builds of GCC.

Since I can't repro, I can't determine which commit actually introduces the regression. If someone is able and willing to determine exactly which commit breaks the M8P I'm willing to attempt to fix the regression if its possible to do so while supporting the newest stable build. Otherwise the only recommendations I have are either:

  • Revert to 3e23332
  • Build on a machine with a more recent version of the toolkit

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants