Cannot run script for Octopus 1.1 mcu flashing, resulting in failure to flash

Hi all I have for many months been struggling with firmware updating the mcu on my Octopus 1.1 F446 board. To work around the issue, I have resorted to updating via the SDCard firmware file method, but I am now at a point where I hope you can help me overcome the problem and get back to upgrading automatically via the Klipper/RatOS GUI. In the attached screenshot I have cut-n-pasted together my scenario which starts with a Klipper update being advertised in the GUI. This morning it was an upgrade from v0.12.0-9 to v0.12.0-10. I click the "Update" button for just the Klipper update (a Beacon update was also available) and the update proceeds as is also shown in the screenshot. But 1,5 minutes later the error message "BIGTREETECT Octopus V1.1 failed to flash: An error occurred while attempting to run script: Running board script /home/pi/printer_data/config/RatOS/boards/btt-octopus-11/flash.sh\n\n" appears and immediately afterwards the messages "Flashing /dev/btt-octopus-11", "Flashing out/klipper.bin to /dev/btt-octopus-11" and "Flashing failed." At this point Klipper has lost its communication with the Octopus board and the only way I can restore it, is through turning the power off and on again. Having restored the communication, I find that the reported firmware version remains the same as before I tried updating. My BTT EBB42 v1.2 and the Raspberry Pi upgrades just fine and the printer prints just fine otherwise. Only the Octopus v1.1 firmware upgrade is a problem for me. Kind regards Jakob
No description
33 Replies
blacksmithforlife
Upload your printer.cfg and klipper.log files
miklschmidt
miklschmidt7mo ago
along with what @blacksmithforlife said, please try running this manually through a terminal (win + r, "cmd", enter), and paste the output here.
ssh pi@ratos.local
sudo ~/printer_data/config/RatOS/boards/btt-octopus-11/make-and-flash-mcu.sh
ssh pi@ratos.local
sudo ~/printer_data/config/RatOS/boards/btt-octopus-11/make-and-flash-mcu.sh
fascinating-indigo
fascinating-indigo7mo ago
Hi both I've added the files in this ZIP. There is indeed some strangeness reported, but I'm not really sure what to make of it. The Klippy.log file is from after I tried the manual flashing you suggested Mikkel. The out come of the command, my next fix based on the first outcome and then the second attempt at the manual flash is also in the ZIP.
miklschmidt
miklschmidt7mo ago
Somehow your klipper installations virtual environment is missing pyserial.. Makes no sense. try:
~/klippy-env/bin/pip install -r ~/klipper/scripts/klippy-requirements.txt
~/klippy-env/bin/pip install -r ~/klipper/scripts/klippy-requirements.txt
Then run sudo ~/printer_data/config/RatOS/boards/btt-octopus-11/make-and-flash-mcu.sh again I don't understand how the toolboard flashes fine, it's using the exact same method.
fascinating-indigo
fascinating-indigo7mo ago
Sorry, still failing 😟
miklschmidt
miklschmidt7mo ago
For some reason python3 is delusional when you flash your octopus.. I wish i had any ideas left. If you run sudo ~/printer_data/config/RatOS/boards/btt-ebb42-12/make-and-flash-mcu.sh, that works?
fascinating-indigo
fascinating-indigo7mo ago
I just launched an 8h print job for the night, so I'll have to try this tomorrow after work. But could it help to repeat the RatOS provisioning flow you have built for when one installs on a blank Raspberry? I have recently renamed the hostname from "ratrig_vc3-500" to "ratrig-vc3-500" as I realized that the underscore character is unsupported, but in a way where I could still use it in the hostname, but doing that caused problems in RatOS (see schreeshot). But as I had that char in the hostname during provisioning then perhaps something didn't get installed correctly... 🧐
No description
miklschmidt
miklschmidt7mo ago
But could it help to repeat the RatOS provisioning flow you have built for when one installs on a blank Raspberry?
That runs the same scripts, so i doubt it. Reflashing RatOS would fix it though.
But as I had that char in the hostname during provisioning then perhaps something didn't get installed correctly...
All that affects is the hostname and mDNS discovery and this message is just a warning.
fascinating-indigo
fascinating-indigo7mo ago
Reflashing sounds like something for my Christmas vacation. Is there a described process for backing up the configuration I have accomplished implementing or is it actually only the printer.cfg file I need to download from the printer and upload after reflashing?
miklschmidt
miklschmidt7mo ago
You can copy paste your printer.cfg and that would be all. If you want to keep your uploaded gcode file and moonraker print history stats etc, you'd have to backup the moonraker database, which is a bit more involved.
fascinating-indigo
fascinating-indigo7mo ago
Nahh, only the configuration is important to me. OK, I think I can manage reflashing then over the weekend. I'll let you know how it goes. Thanks for your help! this
miklschmidt
miklschmidt7mo ago
If you want to be safe, get an additional sd card and use that, then you can always swap back! You're welcome! Sorry i couldn't fix your existing installation. Very curious situation 🤔
fascinating-indigo
fascinating-indigo7mo ago
Hi again @miklschmidt and @blacksmithforlife , I think the problem is that I have an Octopus v1.1 version which RatOS does not support/recognize 🧐 In the screenshots for this post, you can see that I bought an Octopus v.1.1 with an STM32F446ZET6 chip and another screenshot shows that this is not an option I can select in the "Control board selection page". When I try selecting either "Octopus v1.1 F406" or "Octopus Pro 446" then configurator does not recognize the board. And when I select "Octopus v1.1" then the Configurator does recognize the board, but it fails to flash it as is also seen in one of the screenshots. I hate to being a nuisance as I suspect I ought to have known better than to buy this slightly mutated Octopus v1.1 version, but what would you recommend that I do? Get used to flashing manually and if, yes, then which version is best?
No description
No description
No description
No description
No description
No description
No description
No description
miklschmidt
miklschmidt7mo ago
The 446 is the default. Octopus v1.1 = 446. The problem is your python setup, the error you're getting is the one you were getting when running the script manually (it's the same script). Did you try and reflash RatOS? I'm pretty sure your issue goes away
fascinating-indigo
fascinating-indigo7mo ago
I reimaged the SDCard in the Pi with 2023-06-09-RatOS-2.0.2-raspberry-rpi32.img.xz from the GitHub repo and then I worked through the RatOS Printer Setup process until I got to the Board Selection step. When I then selected the Octopus v1.1, the Setup process correctly identified that the firmware version on the board differed from the Klipper version on the Pi, but when automatically flashing it errored out.
miklschmidt
miklschmidt7mo ago
wtf try updating RatOS and the RatOS configurator through mainsail, then go back to /configure and select the octopus v1.1 again, then pick the manual dfu option to flash it instead of automatic, (remove the boot0 jumper again when the dfu device is detected before hitting flash). Then check again if the automatic flashing works.
fascinating-indigo
fascinating-indigo7mo ago
Is the normal operation of the board that I have the BOOT0 jumper set or removed?
miklschmidt
miklschmidt7mo ago
removed
fascinating-indigo
fascinating-indigo7mo ago
OK, I think I got it then. So when you write "then pick the manual dfu option to flash it instead of automatic, (remove the boot0 jumper again when the dfu device is detected before hitting flash)", then this is only relevant when doing manual flashing?
miklschmidt
miklschmidt7mo ago
yes, the boot0 jumper should never be placed on the board outside of manual dfu flashing
fascinating-indigo
fascinating-indigo7mo ago
So I powered down the board and Pi, then set the jumper for BOOT0, then powered both devices up, choose DFU update, removed the jumper with the board powered, started the DFU update and had it complete successfully. When existing to the Mainsail GUI, only information on the Pi was showing. A Emergency Stop and Firmware restart did not restore the connection to the board. I then shut down the Pi and powered both board and Pi off. On turning them on again the Mainsail GUI came up in its normal state and showing the board now running the correct most recent version of Klipper. Then going to http://192.168.20.80/configure?step=1, selecting Octopus v1.1 and then retrying Automatic flash, the process starts but after a while ends in the error shown in the screenshot.
No description
miklschmidt
miklschmidt7mo ago
I'm stumped. I don't know what's going on here. I will try and reproduce when i get my machine with the octopus back online, but i flashed that one countless times automatically on the most recent version so i don't expect it to fail (and i'd assume someone else had reported the issue as well as it's a quite common board, it's the default afterall). You didn't install any other software, right?
fascinating-indigo
fascinating-indigo7mo ago
No, no other software installed.
miklschmidt
miklschmidt7mo ago
Gotcha, i'll post an update once i know more (it'll probably be a while as i have a lot of stuff going on atm).
fascinating-indigo
fascinating-indigo7mo ago
Totally fine 👍
miklschmidt
miklschmidt7mo ago
Thanks for reporting and assisting with debugging!
fascinating-indigo
fascinating-indigo7mo ago
You're welcome. After supper I'll try some random things, like another USB cable, but as the printer otherwise prints fine, I'm not thinking it will be a breakthrough...
fascinating-indigo
fascinating-indigo7mo ago
Good news @miklschmidt , I've found a way to both reproduce the issue and fix it 🎉 In the attached text file I've documented 22 steps I can repeat to both show and fix the problem.
miklschmidt
miklschmidt7mo ago
How strange that a reinstall of pyserial makes it work, and that it didn't fail for the other boards as well. I will need to check this with the next image, thank you so much!! For anyone else coming across this topic, the fix seems to be sudo pip install --upgrade pyserial
fascinating-indigo
fascinating-indigo7mo ago
So something interesting happend today @miklschmidt, the Klipper v0.12.0-12 to v0.12.0-13 update became available and I used the "Update all components" feature on the /config page to implement the Klipper update as well as the KlipperScreen and RatOS update. That update failed to update the MCU, but then I power-cycled the Octopus v1.1 board and used the provisioning flow via the /configuration page, the MCU update suceeded... 🧐 I captured screenshots of this process. Let me know if there's something else I can provide you which is helpful. Maybe next time an update is made available, there is a way for me to put the system into "debug mode" to capture useful log files for you?
No description
No description
No description
No description
No description
No description
No description
No description
No description
miklschmidt
miklschmidt7mo ago
There's a log file in /var/log/ratos-configurator.log I'm pretty sure it's the same deal though. Pyserial is being fucky. And just for your octopus.. for reasons...
fascinating-indigo
fascinating-indigo7mo ago
fascinating-indigo
fascinating-indigo7mo ago
More news @miklschmidt , today Klipper update v0.12.0-13 to v0.12.0-31 (and a Klipperscreen update) became available. To try a theory, I power-cycled the board and raspberry before hitting "Update all components". And lo and behold, the MCU successfully completed the update.
No description
No description
No description
No description
No description
No description