Unable to flash Octopus 1.1 on RatOS 2 alpha5
Hi,
Having been a very happy camper running buster-based RatOS 2 alpha I proceeded and reinstalled with the alpha 5 bullseye image and merged my old conf into the new one. Everything was fine until sometime after I applied updates which included klipper to v0.11.0-86-g6026a99a and sometime after that the board would no longer show up on the USB bus following a firmware restart.
I have found myself in the position of having an inaccessible MCU and so far I have been able to dig myself out of that particular hole by setting the board to DFU mode and flashing klipper with 'make flash...' but now there seems to be something wrong with the build environment. The steps I have been following to build and flash is to:
# set octopus to DFU mode, and reset. lsusb shows:
# Bus 001 Device 003: ID 0483:df11 STMicroelectronics STM Device in DFU Mode
cd klipper
../printer_data/config/RatOS/boards/btt-octopus-11/firmware.config .config
make clean
make flash FLASH_DEVICE="0483:df11"
The flashing part bails however with:
Flashing out/klipper.bin to 0483:df11
Usage: flash_usb.py [options] -t <type> -d <device> <klipper.bin>
flash_usb.py: error: option -s: invalid integer value: ''
make: *** [src/stm32/Makefile:98: flash] Error 2
As far as I can tell it fails because no valid argument is set for -s. Making the Makefile echo the flash command shows:
@python3 ./scripts/flash_usb.py -t stm32f446xx -d 0483:df11 -s out/klipper.bin
In the same Makefile it appears that -s is set to "$(CONFIG_FLASH_APPLICATION_ADDRESS)" but I cannot see where that variable is supposed to come from.
Any ideas?
9 Replies
Have you tried flashing it using SD card and the compiled firmware binary from the machine tab (just like the first time flashing it in the documentation)?
Haven't tried that actually. When I previously have attempted flashing via SD-card I have never succeeded. I tried the first time but it would never take so I suspected I got the wrong combination of SD card size, block size, FAT parameters (on Linux) and since I had better success with dfu-util or stm32cube programmer.
But if course, if I can fix it that way...
So I found a 16GB SD card which i formated with (Linux) fdisk with 1 primary partition of type W95 FAT32 on which i created a vfat file system. There is no specific mkfs.fat32 in Linux and vfat should be backwards compatible.
Copied the printer_data/config/firmware_binaries/firmware-btt-octopus-11.bin to firmware.bin on the root of the sd-card partition, removed boot0 jumper on the octopus and powered on with sd-card and it will not upgrade.
Enabling boot0 and resetting the board puts it into DFU mode again in which I tried to flash the same firmware with
dfu-util -d ,0483:df11 -R -a 0 -s 0x8008000:leave -D ~pi/printer_data/config/firmware_binaries/firmware-btt-octopus-11.bin
This sort if suceeds since it resets and presents a serial device named:
/dev/serial/by-id/usb-Klipper_stm32f446xx_btt-octopus-11-if00
That name is of course not what it should be given the RatOS Octoups firmware config file.
Resetting the board without boot0 will not cause it to not to show up at all again but DFU works with boot0 jumper in.
Could I have borked the bootloader perhaps?
That name is of course not what it should be given the RatOS Octoups firmware config file.Yes it is. That means it got the right chip ID (flashed succesfully). It should now be mapped to /dev/btt-octopus-11 via udev. that said You should've just used the configurator
Ah, thanks for pointing that out @miklschmidt! I forgot that the short name was directly under /dev.
The remaining issue is why it wont boot with the boot0 jumper removed. I did use the configurator to configure the octopus and toolboard when redeploying with alpha5 and that worked just fine and everything worked. And then at some point, the board would no longer show up after a reboot unless in DFU mode.
that sounds very strange
And after flashing it again it still doesn't show up?
wihout boot0 that is
Exactly.
And I am trying to think about something I did but the only thing that was done to the card was to upgrade klipper using the RatOS alpha 5 GUI - after which it did work as well.
It should be added that it is not out of the question that it has some kind of hardware issue. It did have a little accident when I added a cooling fan some time back when the fan connector was yanked from its socket when powered on. That seems to have fried the fan PWM regulator IC since none of the fan outputs work. All the other fans is on the EBB42 so I could still use the board.
Try to unplug everything except power and usb and see if it shows up, if it doesn't. I don't know, might be damaged 🤷♂️
I will try that when I am back at the printer next week. If everything fails I have a spare Octopus board ready.
So I finally had some time to investigate this further. Without BOOT0 the board will not show up at all when power cycled. With BOOT0 and one press of the reset button it will enter DFU mode.
From DFU I can flash it using dfu-util after which it will reset and actually present itself as a klipper device with all the correct characteristics and it can be used from RatOS.
Another power cycle will render the board inop again, BOOT0 setting regardless but it will again enter DFU mode and the process can be repeated.
As this starts to look like a bootloader issue I reflashed the bootloader with STM32Cube programmer using the firmware image from BTT GitHub and now the board has started to work normally again. It even booted the correct klipper firmware I had previously flashed.
There was no messing on my part with tools like dfu-util or "make flash..." leading up to the point when it went inop and it had undergone quite a number of automatic flashing procedures on RatOS 2 before so I am not sure what happened here.
i guess there was some transient flaw in the flashing scripts that existed when I redeployed the bullseye based RatOS 2a image causing the bootloader to break, possibly by not using the correct offset when writing the image.
I also guess that the inability to install firmware via SD-card also could be explained by a broken bootloader.
The upside to all this is that it is quite easy to rescue these boards using the STM32 programmer.
The spare Octopus board remains in the antistatic bag for now. 🙂
That's extraordinarily strange. It shouldn't be possible to mess up the bootloader from simple DFU flashing, it's in a different isolated memory space.
I also guess that the inability to install firmware via SD-card also could be explained by a broken bootloader.For sure!
The spare Octopus board remains in the antistatic bag for now.Never go down on spares! 🙂