Flashing Klipper friendly bootloader on BTT SKR Mini E3 v2

This is a very brief overview on how to install Arksine’s katapult (formerly CanBoot) onto the SKR Mini E3 v2 without any additional special hardware. The primary motivation is to allow updating the Mini via USB using the standard Klipper make flash command with no need for SD card based flashing. The same fundamental approach can be used on other BTT SKR boards, but exact configuration settings will need to be adjusted accordingly.

This procedure is similar to the one outlined by @Sineos in CanBoot: Flash BTT SKR 1.3 / 1.4 / 1.4 Turbo, but instead of requiring any additional hardware it relies purely on the katapult “deployer mode”.

CAUTION: This will remove the BTT bootloader and replace it with katapult. You will no longer be able to update the firmware using the SD card! I strongly recommend that you back-up the original bootloader first by using the following command: ~/klippy-env/bin/python ~/klipper/scripts/dump_mcu.py -l 0x7000 /dev/ttyACM0 ~/bootloader_backup.bin. If anything goes wrong during this process your SKR board will become unusable until a functional bootloader is installed. This will require additional external programming hardware.

Process Steps

  1. Install katapult following the instructions on GitHub: katapult.

  2. Use the following configuration during make menuconfig. Make sure each line is exactly as shown in the screen grab below, paying particular attention to (!PA14) and (PA13) pin settings:

  3. Compile katapult and then transfer the deployer.bin file from ~/katapult/out directory to a suitable SD card.

  4. Rename deployer.bin on the SD card to firmware.bin.

  5. Insert the SD card into BTT SKR Mini E3 v2 and power up the SKR. Note the Status LED will briefly flash as the bootloader is being flashed.

  6. The SKR status LED will start flashing slowly as the board resets and enters the katapult bootloader mode. If the bootloader mode is needed at a later time, rapidly double-clicking the RESET button on the board with place it in bootloader mode.

  7. When configuring klipper for the modified board using make menuconfig, do not use 28KiB bootloader setting noted in the example klipper configuration file. Instead use 8KiB bootloader setting in order to be compatible with the newly installed katapult bootloader.

  8. Flash Klipper onto the modified SKR board using the standard flash command make flash FLASH_DEVICE=/dev/ttyACM0. Make sure to use the correct device name for your specific installation, for example it could be make flash FLASH_DEVICE=/dev/ttyACM1, etc.

That’s all folks! Many thanks to Arksine for his ongoing development of the Klipper ecosystem!

EDIT 2024-03-04: Slightly reworded steps 7 & 8 for clarity.
EDIT 2024-03-18: Included additional pin note in step 2.

7 Likes

after performing this my USB on my main board appears to be dead. Cable worked before this, afterwards when typing “ls /dev/serial/by-id” im getting directory dosent exist. help would be greatly appreciated as im new to klipper. Im not new to firmware and linux in general but im new to klipper

Hi. When you say USB “appears to be dead”, do you mean in boot loader mode the USB is not functioning? Implying that you are unable to flash Klipper onto it? If so, did you make sure to set !PA14 in GPIO pins to set on boot loader entry as shown in my screen capture above? This is absolutely needed for the boot loader to enable USB on the SKR3 Mini v2.

Yes. I properly set my GPIO pins, but when in bootloader mode, if I attempt to do find my unique serial id it returns directory not found.

  • Is the SKR status LED flashing slowly indicating that the board is in the katapult bootloader mode?
  • Have you tried issuing a lsusb command on the Pi to check if the board is detected?
  • Do you have a /dev/ttyACM1 (or perhaps /dev/ttyACM0) device? If yes, you may be affected by Debian 11 (Bullseye) udev bug - No board or serial found

i did have the buggy version, however even after updating and running the script to remidy the issue im still getting the same results, directory not found. And yes the LED is slowly flashing. and upon further investigation the board isn’t being recognized

Are you saying that the board is not shown when using lsusb? If it is not working then there had to be an issue with configuration via make menuconfig. I have done the flash this way many times and it worked every single time without any issues. Is your board definitely v2? Is the CPU STM32F103? Can you double-check that the make menuconfig settings are exactly as shown? Beyond that I have nothing else to offer, unfortunately…

Maybe I’m misunderstanding the issue, but when your board is in bootloader mode then it is like being in the BIOS setup and wondering why no Windows desktop is showing up.

You need to flash a new Klipper first following @ReXT3D point 8:

As /dev/ttyACM1 is not stable, unplug the board, replug it and then use sudo dmesg to get the correct path.

Did you ever get it working?

Thank you very much for this great writeup (and the following help).
I was able to follow these instructions to install a much more friendly bootloader and now can be on my way to setting up canbus on the printer.
I had two speed bumps.

  • The first was the skr mini e3 v2 I had, required a fat16 (an obsolete filesystem since 2000) microsd to flash the created file.
  • I had this debian11 udev bug, which took a while before spotting.

Thanks a lot Sineos. Now I understand why people think there is such things as Gods and Prophets :smiley:

2 Likes

2 posts were merged into an existing topic: MCU not responding to anything

when i try step 8 i get the following
Failed to flash to /dev/ttyACM1: Unable to find serial ‘by-path’ folder

If the device is already in bootloader mode it can be flashed with the
following command:
make flash FLASH_DEVICE=1eaf:0003
OR
make flash FLASH_DEVICE=1209:beba

If attempting to flash via 3.3V serial, then use:
make serialflash FLASH_DEVICE=/dev/ttyACM1
whats the fix?

Hello All,

I’m in a similar situation to Blueberry. I was able to successfully follow ReXT3D’s procedure (which is excellent btw), getting Katapult flashed onto my Mini E3 V2 (from an LDO Voron Switchwire kit). That part worked fine. I was able to successfully run the make flash command, in my case “make flash FLASH_DEVICE=/dev/ttyACM0”.

Now this is where my old noob skull gets lost, kinda similar to what Blueberry was seeing. AFTER this point, I cannot see the MCU, after rebooting, power off / on, etc. The ls /dev/serial/by-id/* command returns nothing. lsusb simply returns basic USB hub info from the Pi, no MCU. All that stuff leads me to believe I’ve goofed somewhere in the make menuconfig, and that the klipper.bin file I’m flashing is no good. I can easily get back into the bootloader by tapping the reset button on the board, so the hardware is working, as is Katapult.

The question is: what’s wrong in the make menuconfig? I followed ReXT3D’s process to the letter, but still haven’t been able to see the MCU after the flash. I’ve followed the bog-standard Mini E3 V2 Klipper make menuconfig, switching to the 8kb instead of 28kb for Katapult, but no luck.

Any idea how to troubleshoot this? I feel like I’m missing some Captain Obvious thing here, but no idea what. Thanks in advance to anyone who reads this!

So if double-tapping RESET puts you into bootloader mode with the SKR status LED flashing slowly, the bootloader has been correctly installed and is working.

This means, as you mentioned, that there is something wrong with your klipper configuration made using make menuconfig for the Mini E3 v2. This configuration should be exactly identical to the example klipper configuration file except for the bootloader offset:

# This file contains common pin mappings for the BIGTREETECH SKR mini
# E3 v2.0. To use this config, the firmware should be compiled for the
# STM32F103 with a "8KiB bootloader" and USB communication. Also,
# select "Enable extra low-level configuration options" and configure
# "GPIO pins to set at micro-controller startup" to "!PA14".

Note that I changed “28KiB bootloader” in the above excerpt to “8KiB bootloader”. You also have to remember to select “Enable extra low-level configuration options” and configure “GPIO pins to set at micro-controller startup” to “!PA14”. If either of these two are not set correctly klipper will not function.

Funny thing, I read all that in the instructions, THOUGHT I had followed everything to the letter, only to realize I had used !PA13 instead of !PA14. D’OH!!! I just did the reflash, and after reboot I can FINALLY see the MCU flashed to Klipper.

Thanks very much for the reply, and original procedure! How the heck I missed something SO obvious for SO long is beyond me!

2 Likes

So I got the FW to load and can get it into boot loader mode. But I made a mistake and did not ! before PA14. I now cannot get it to reload the original FW or the corrected one !PA14.

Any Ideas it like it will not longer read the sdcard. But the light comes on showing and sdcard is inserted.

Hi and welcome to the community. Unfortunately the omission of !PA14 puts you in a world of pain with the Mini. If PA14 is not pulled down on startup, the USB port remains disabled, giving you the exact issue you are seeing. The katapult bootloader can only load new firmware or updated bootloader with USB, and USB is now “permanently” disabled. You will not be able to load new firmware with an SD card, because katapult does not support this method of firmware loading. You can read a bit more about this issue here:

[BUG] SKR mini E3 V2.0 USB not working with debugger · Issue #431 · bigtreetech/BIGTREETECH-SKR-mini-E3 (github.com)

If you are handy with electronics, you can try to force PA14 low by EXTREMELY carefully soldering a jumper wire between PA14 pin (probably near the U7 MOSFET where there is more room) and the ground. This will force pull down the PA14 pin during power-up and restore USB functionality. You can then flash the corrected katapult loader per my original instructions and finally remove the jumper wire.

So PA14 just needs to be pulled low if I am reading you correctly so can I just pin it to any ground because there is a ground pin I could use a single dupont plug.

I just had a look at the schematic on BTT GitHub. It looks like, theoretically, you might be able to jumper pins 3 (GND) & 4 (SWCLK / PA14) on the SWD header (J11).

Note that I have never done this (or anything like this), and herewith absolve myself of any responsibly for potential magic smoke or a cooked MCU…

Considering the state its in now its unusable so it will be in the same state either way. I shorted those pins no magic smoke but also did not load the new firmware either.

I am going to see if I flash with STlink or windea the firmware to see if it can fix it.