Fill out above information andin all cases attach yourklippy.logfile (use zip to compress it, if too big). Pasting yourprinter.cfgis not needed Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered klippy (1).log (101.5 KB)
there
Describe your issue:
Has anyone encountered this error when trying to flash firmware to an Octopus V1.1
How do you know, that the Octopus is in DFU Mode? In your screen shot, it looks like you login and try the flash operation immediately.
Could you do an lsusb command and post the results here?
Just as a comment, when posting screen results, It’s preferred that you copy the terminal output into the </> option (above) like:
Microsoft Windows [Version 10.0.22631.4037]
(c) Microsoft Corporation. All rights reserved.
C:\Users\mykep>ssh biqu@cm4-test
biqu@cm4-test's password:
Linux cm4-test 6.6.20+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.20-1+rpt1 (2024-03-07) 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: Sat Aug 17 02:10:36 2024 from fe80::2048:9080:cf4a:792d%wlan0
biqu@cm4-test:~ $ lsusb
Bus 001 Device 004: ID 0483:df11 STMicroelectronics STM Device in DFU Mode
Bus 001 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
biqu@cm4-test:~ $
Yes this happened repeatedly. That was one of the many attempts; I was able to see the Octopus with the lsusb command. I can send when I get back home.
Would it download without seeing the board in DFU mode first?
Thanks for the info on the code; I’m new to this here
Looking at your screenshot, I’m going to suggest that you go straight to the dfu-util command rather than let make flash prepare it for you. I’m not sure about the address of 0x8008000 that is being used with that command.
Could you try:
sudo dfu-util -a 0 -D ~/klipper/out/klipper.bin --dfuse-address 0x08000000:force:mass-erase:leave -d 0483:df11
biqu@BTT-CB1:~/klipper$ lsusb
Bus 008 Device 002: ID 1d50:614e OpenMoko, Inc. rp2040
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 002: ID 0483:df11 STMicroelectronics STM Device in DFU Mode
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
biqu@BTT-CB1:~/klipper$ sudo dfu-util -a 0 -D ~/klipper/out/klipper.bin --dfuse-address 0x08000000:force:mass-erase:leave -d 0483:df11
dfu-util 0.11-dev
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 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: Warning: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release
Opening DFU capable USB device...
Device ID 0483:df11
Device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Interface #0 ...
Determining device status...
DFU state(10) = dfuERROR, status(10) = Device's firmware is corrupt. It cannot return to run-time (non-DFU) operations
Clearing status
Determining device status...
DFU state(2) = dfuIDLE, status(0) = No error condition is present
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash "
Performing mass erase, this can take a moment
Setting timeout to 35 seconds
Downloading element to address = 0x08000000, size = 31812
Erase [=========================] 100% 31812 bytes
Erase done.
Download [=========================] 100% 31812 bytes
Download done.
File downloaded successfully
Submitting leave request...
dfu-util: Error during download get_status: -4 (LIBUSB_ERROR_NO_DEVICE)
biqu@BTT-CB1:~/klipper$
You do get a get_status error when you do the DFU command but it shoudl work fine, I just tried it here:
biqu@cm4-test:~ $ sudo dfu-util -a 0 -D ~/klipper/out/klipper.bin --dfuse-address 0x08000000:force:mass-erase:leave -d 0483:df11
dfu-util 0.11
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 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: Warning: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release
Opening DFU capable USB device...
Device ID 0483:df11
Device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Interface #0 ...
Determining device status...
DFU state(2) = dfuIDLE, status(0) = No error condition is present
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 element to address = 0x08000000, size = 37244
Erase [=========================] 100% 37244 bytes
Erase done.
Download [=========================] 100% 37244 bytes
Download done.
File downloaded successfully
Submitting leave request...
dfu-util: Error during download get_status
biqu@cm4-test:~ $
Check to see if you can connect the Octopus to your Klipper host once the operation is complete.
Oh man, can it be that simple? Well, now the PI can’t seem to find the board. biqu@BTT-CB1:~$ ls /dev/serial/by-id/* /dev/serial/by-id/usb-Klipper_rp2040_btt_acc-if00 biqu@BTT-CB1:~$
I’m guessing this is probably something simple; but I can’t seem to figure out why is it not recognizing it.
Last login: Fri Aug 23 16:17:37 2024 from 192.168.214.141
biqu@BTT-CB1:~$ ls /dev/serial/by-id/*
/dev/serial/by-id/usb-Klipper_rp2040_btt_acc-if00
biqu@BTT-CB1:~$
Yes, correct. The other board is the BTT ADXL… the reason why I am trying to load another config to the Octopus. The only other thing connected to the PI is the ADXL and the USB cord to the Octopus.
Do you think loading it via SDcard would work? I don’t have a 4gb SD card currently.
This line could explain you initial problem.
There are some mcu which cannot go back into the normal run-time mode after flashing (eg timmits V0-Display with STM32F042F6Px has this problem too)
I do not have a Octopus or F446 based board so just guessing.
From the log it looks like it got flashed
and just the reset to runtime mode did not worked
In the end I guess you sucessfully flashed you board but to 99% you have overwritten the stock BTT sd update bootloader so no sd updating for you until you restoring it.
You are in luck since the octopus is one of the less board BTT has uploaded the bootlaoder to github too:
I did not used an .hex file yet so probably stick to the btt manual but probably better use the latest java and stm32cube versions.
Also it is a great idea to dump what is currently on your octopus.
Follow their pdf including page 11 - then press the “Read All” button that you can access throuch the drop down next to the “read” button (pic reference btt manual p11 second pic top right corner)
