Experiment with automated mcu flashing

Several months ago, I put together a (very raw) prototype to assist with micro-controller flashing from the Klipper API Server. The main idea is to make it easier for users to build, deploy, and maintain the micro-controller code. This topic is a place for discussions on this experiment.

The code for this experiment is at https://github.com/KevinOConnor/klipper-dev/tree/work-flash-20210519

The core idea is to place a section in the main printer.cfg with the Kconfig settings and flashing parameters needed for the micro-controller. For example:

[flash_mcu btt-skr-mini-mz]
flash_method: sdcard,btt-skr-mini-mz
kconfig:
  CONFIG_MACH_STM32=y
  CONFIG_MACH_STM32F103=y
  CONFIG_STM32_FLASH_START_7000=y
  CONFIG_LOW_LEVEL_OPTIONS=y
  CONFIG_INITIAL_PINS="!PA14"

With that info, it should be possible for the graphical frontends to be able to command Klipper to build and flash the mcu.

Alas, I have not had time to work further on this experiment. It’s unclear when I’ll be able to work on it again.

There was a previous discussion on this topic at https://github.com/Klipper3d/klipper/pull/4307

-Kevin

7 Likes

I was following your experimental example closely, but have not chimed in on it yet. As I am running several multi-MCU setups (5-8 MCUs each with different initial_pins configs), I would be super happy to help testing if needed.

Do we need to directly integrate with Moonraker and UIs like Mainsail - or can’t we first add a quick python script (“flash_all_mcus.py”) for development and testing the functionality?

I have to say, this seems like something that might be smarter to integrate into a secondary API server like Moonraker.

Love the idea though

Hello everyone, any news here? Is this continuing? I’d really like to flash all MCUs after an update, which seems to happen every few minutes. But preferably automatically.

I think this is more a thing for KIAUH or at least the frontends.

1 Like

Which is completely unnecessary. In fact, updates requiring flashing the MCU are quite rare, and Klipper will inform you when it is required.

Is there perhaps a routine that triggers the necessary updates by flashing? To be precise, manually flashing is quite annoying.

For me its fun.

Not really. And it can’t do any harm if all software versions are the same. Also, I didn’t mention that I want to flash the MCUs via the CAN bus. I don’t think Kiauh offers that.

Also, it adds no value. Being rare, it is not a priority. The focus of this change would have been on first-time setups, as many users struggle with the settings. Of course a benefit for updating as well.

Especially in combination with Katapult and a little bit of bash scripting, you could easily automate this. Something along these lines:

#!/bin/bash

CONFIG_FILE="ebb42.config"

error_exit() {
    echo "$1"
    exit 1
}
make clean KCONFIG_CONFIG="$CONFIG_FILE" || error_exit "Failed to clean old build."
make olddefconfig KCONFIG_CONFIG="$CONFIG_FILE" || error_exit "Failed to update make arguments."
make KCONFIG_CONFIG="$CONFIG_FILE" || error_exit "Firmware build failed."
make flash FLASH_DEVICE="<id string>" KCONFIG_CONFIG="$CONFIG_FILE" || error_exit "Flash failed. Check the device path."
  • The relevant configurations need to be created once, e.g. with make menuconfig KCONFIG_CONFIG=ebb42.config
  • This script is largely untested, written from top of my head.
  • If it doesn’t work, feel free to ask ChatGPT.
  • You can extend this script with as many configurations as you would like.

Edit: Little fix. make menuconfig in the script seems unneeded.
Edit2: Let’s add a make clean to be on the safe side.

2 Likes

I’ve been using it for a long time GitHub - juliapythoncpp/moonraker-mcu-flasher
All boards must have a katapult loader. I have SKR3 and EBB42 board.
Instructions https://canbus.esoterical.online/

1 Like

For what it is worth, I recommend always being prepared to flash the micro-controllers when updating the Klipper software. Klipper is one piece of software that runs on both a general purpose computer and one or more micro-controllers. Any time the software is updated it may be necessary to update the micro-controllers to that software.

It is true that we haven’t made too many recent “breaking changes” that require flashing the micro-controller. However, this is unlikely to always stay like this. We’ve been reluctant to make changes that require reflashing because we know it’s very painful for some users to do that. If we can get to the point where flashing is easier, I certainly see the rate of flash requiring changes increasing.

As for the status of this topic (automated mcu flashing) - I’d still like to see it be completed, but it competes with many other projects that I have ongoing. I have not progressed substantially from my last comments on this thread.

Cheers,
-Kevin

1 Like

Thank you very much, Kevin and everyone else, for your answers. So, I don’t see any harm in the fact that all MCUs are the same as the current Klipper version?! However, I initially asked if there were CLI commands for “Menuconfig,” and Sineos started to answer with a config file. But what should be in that file?

There is no direct CLI command. The only option is detailed above by using the respective make menuconfig command (also shown above) and then reusing the resulting .config file for the CLI process.