Arksine
Get to katapult bootloader mode via serial UART1
Hi, I have modified a qidi x-plus 3 motherboard to run standard klipper. Everything is working, there is a toolhead MCU - a rp2040 running over USB, and the main MCU running an STM32F401 designed to communicate directly with the SOC via uart over /dev/ttyS0
Both MCUs now have katapult bootloader loaded successfully, and I was able to load klipper binaries onto both initially, using the flashtool.py script.
With regard to future klipper updates, now that klipper has been loaded on both, I can confirm that the rp2040 is able to be put into bootloader mode using the flash_usb script's "enter_bootloader" function.
My problem now is trying to update the STM320F401 without having to physically open the back of the machine to get at boot-0 or reset pins. I cannot figure out a method to enter bootloader mode over the /dev/ttyS0 serial port so that I can run the flash tool and update the firmware. I have only been able to get into bootloader by double pressing reset so far.
Does anyone have suggestions on how I can enter bootloader mode through the command line on a serial connection to the MCU?
Any ideas appreciated. Thx!
I tried katapult on kingroon kp3s pro v2 printer. It has rp2040 and gd32f303 (stm32f103 clone). I checked katapult only on gd32f303 it is connected as /dev/ttyS0 as in your case. katapult deployer works as expected but I can do nothing with it after deploying. It starts something located in it's configured offset (8 kib) and became unavailable. If katapult was deployed through stlink on previously erased flash - it works as it running on itself all the time.
But once I was successfully connected to bootloader. I reseted it through stlink and in the same time started flashtool.py. I tried to run flashtool.py -b 250000 -d /dev/ttyS0 and reset mcu through stlink during flashtool is trying to connect but nothing. I guess you can try to reset mcu (if klipper is working) and run flashtool.py exactly after firmware_restart was sent.
My conclusions.
- In case you have klipper firmware installed and working you can try to restart mcu through the klipper command and trying to connect to it with flashtool.py. Or in klipper documentation described a command which can be used to force bootloader staying in itself on the next boot. But it doesn't work for me.
- katapult is useless in deployer mode because it starts something located in it's configured offset and mcu program didn't start but bootloader become anavailable.
- flashtool.py didn't waiting bootloader to appear and if this is true it completely useless in my case. I prefer to stay on default kingroon bootloader because it gives ability to reflash on mcu boot through sd card without printer disassembling.
On my printer i have about 15 sec of main board staying alive after power was turned off. mcu is turned off too. So i can restart it by powering off wait 2-4 sec and powering on. But flashtool.py in this case can't connect to bootloader too. Maybe I am wrong but I spent a lot of time in experiments with katapult/stlink/klipper.
To @Arksine: is it possible to make something in bootloader to wait for flashtool.py command? For example: bootloader starts, waiting something from flashtool.py for 5 sec, starts application. Flashtool continuously sending something to /dev/ttyS0.
I have a MKS Skipr. Since today i use the following to update klipper on the main mcu, without katapult. https://www.klipper3d.org/SDCard_Updates.html
Sdcard needs to be mounted. You need to find or add a board in file ~/klipper/scripts/spi_flash/board_defs.py that is compatible with your board Looking at schematics, i have same mcu and sdcard is connected on same spi and cs pin as mks monster8
sudo service klipper stop ~/klipper/./scripts/flash-sdcard.sh -b 250000 /dev/ttyS0 monster8 sudo service klipper start
~/klipper/./scripts/flash-sdcard.sh -b 250000 /dev/ttyS0 monster8
Flashing /home/nico/klipper/out/klipper.bin to /dev/ttyS0 Checking FatFS CFFI Build... Connecting to MCU...Connected Checking Current MCU Configuration...Done MCU needs restart: is_config=1, is_shutdown=0 Attempting MCU Reset...Done Waiting for device to reconnect...Done Connecting to MCU...Connected Initializing SD Card and Mounting file system...
SD Card Information: Version: 2.0 SDHC/SDXC: False Write Protected: False Sectors: 3854336 manufacturer_id: 2 oem_id: TM product_name: SA02G product_revision: 0.3 serial_number: 9C99D4A2 manufacturing_date: 3/2009 capacity: 1882.0 MiB fs_type: FAT32 volume_label: b'USB STICK' volume_serial: 1992074428 Uploading Klipper Firmware to SD Card...Done Validating Upload...Done Firmware Upload Complete: firmware.bin, Size: 30056, Checksum (SHA1): 1FD0A586DAE7C77B3BBCA8DF873DC5EBEA339948 Attempting MCU Reset...Done Waiting for device to reconnect...Done Connecting to MCU...............Connected Verifying Flash...Version matched...Done Firmware Flash Successful Current Firmware: v0.12.0-410-gcf3b0475d-dirty-20250113_005947-mkspi Attempting MCU Reset...Done SD Card Flash Complete
~/klipper/./scripts/flash-sdcard.sh -b 250000 /dev/ttyS0 monster8
Flashing /home/nico/klipper/out/klipper.bin to /dev/ttyS0 Checking FatFS CFFI Build... Connecting to MCU...Connected Checking Current MCU Configuration...Done MCU needs restart: is_config=1, is_shutdown=0 Attempting MCU Reset...Done Waiting for device to reconnect...Done Connecting to MCU...Connected Initializing SD Card and Mounting file system...
SD Card Information: Version: 2.0 SDHC/SDXC: False Write Protected: False Sectors: 3854336 manufacturer_id: 2 oem_id: TM product_name: SA02G product_revision: 0.3 serial_number: 9C99D4A2 manufacturing_date: 3/2009 capacity: 1882.0 MiB fs_type: FAT32 volume_label: b'USB STICK' volume_serial: 1992074428 Uploading Klipper Firmware to SD Card...Done Validating Upload...Done Firmware Upload Complete: firmware.bin, Size: 30056, Checksum (SHA1): 1FD0A586DAE7C77B3BBCA8DF873DC5EBEA339948 Attempting MCU Reset...Done Waiting for device to reconnect...Done Connecting to MCU...............Connected Verifying Flash...Version matched...Done Firmware Flash Successful Current Firmware: v0.12.0-410-gcf3b0475d-dirty-20250113_005947-mkspi Attempting MCU Reset...Done SD Card Flash Complete
Actually you are not updating firmware through /dev/ttyS0, you just writing a file to SD card which will be written to flash memory from there to your mcu at next time when bootloader starts. This method has some limitations. By default file names longer than 8 symbols are not supported. I can't write a file to modern SD card with 128 Gb or 64 Gb of memory. Only 8 Gb works for me. It works for my printer but it is inconvenient and needs some changes https://github.com/Lebensgefahr/kingroon_kp3s_pro_v2?tab=readme-ov-file#write-firmware-image-to-sd-card-in-printer-slot It is easier to write a file to SD card somewhere else. And finally I need to turn off the printer and turn on it again. Restart is not working in my case. With Katapult you can update firmware without SD card at all and you can restart klipper firmware and stay in bootloader. And you can update Katapult with it's deployer or change your bootloader to Katapult without stlink programmer. And Katapult is open source project. I added neopixel leds enabling at initialization stage.
I cannot figure out a method to enter bootloader mode over the /dev/ttyS0 serial port so that I can run the flash tool and update the firmware. I have only been able to get into bootloader by double pressing reset so far.
Check this topic. It gives answer on your question. And I added this changes to flashtool.py maybe it will appear in Katapult repo. https://klipper.discourse.group/t/how-to-enter-into-bootloader-with-serial-connected-mcu/21251/8
urche0n-82 Was looking for a way to update firmware without opening his printer, because with katapult it was not possible for him and you.
With ~/klipper/./scripts/flash-sdcard.sh this is possible . You do not need to press boot or reset button.
urche0n-82 Was looking for a way to update firmware without opening his printer, because with katapult it was not possible for him and you.
With ~/klipper/./scripts/flash-sdcard.sh this is possible . You do not need to press boot or reset button.
It is possible. There is a special command for klipper to restart mcu into bootloader for virtual serial and physical serial devices. It works with Katapult. The main goal of Katapult for me - I don't need SD card to update firmware. Check this https://klipper.discourse.group/t/how-to-enter-into-bootloader-with-serial-connected-mcu/21251/8
It is possible. There is a special command for klipper to restart mcu into bootloader for virtual serial and physical serial devices. It works with Katapult. The main goal of Katapult for me - I don't need SD card to update firmware. Check this https://klipper.discourse.group/t/how-to-enter-into-bootloader-with-serial-connected-mcu/21251/8
This is amazing. I have tested your pull request version of the flashtool.py and using the -r argument I am now able to put my stm32f401 into bootloader mode first, then flash updated klipper successfully - no physical access to the board required to get to bootloader, and no need for sd cards.
I am also able to use this to put my rp2040 toolhead mcu into bootloader mode over usb with the same -r argument, and then the katapult usb bootloader appears in my usb id list, so I can flash to that.
Thank you so much for the pull request, even if they don't accept this into the main branch, i'll be using your version going forward :) But hopefully they merge it in.
Ok. Thank you for the information, will try katapult with special uart command also
It is possible. There is a special command for klipper to restart mcu into bootloader for virtual serial and physical serial devices. It works with Katapult. The main goal of Katapult for me - I don't need SD card to update firmware. Check this https://klipper.discourse.group/t/how-to-enter-into-bootloader-with-serial-connected-mcu/21251/8
This is amazing. I have tested your pull request version of the flashtool.py and using the -r argument I am now able to put my stm32f401 into bootloader mode first, then flash updated klipper successfully - no physical access to the board required to get to bootloader, and no need for sd cards.
I am also able to use this to put my rp2040 toolhead mcu into bootloader mode over usb with the same -r argument, and then the katapult usb bootloader appears in my usb id list, so I can flash to that.
Thank you so much for the pull request, even if they don't accept this into the main branch, i'll be using your version going forward :) But hopefully they merge it in.
How did you change rp2040 bootloader? I want to change it too to katapult.
I worked with flashtool.py for some time during bootloader source code modifying and discovered that this tool can't send separate command to exit from bootloader. I added parameter and method for this behavior.
How do you think is this parameter useful for other people?
So we can check every step. Send request to bootloader -r, query it with -q and exit from it with -e.
How did you change rp2040 bootloader? I want to change it too to katapult.
For my machine, there is a walkthrough to get it from manufacturer klipper back to mainline klipper, and one of the sections relates to putting the rp2040 into DFU mode to flash a katapult binary to it, then once that's loaded, using that to flash latest klipper.
FreeQIDI Walkthrough - Updating the THR toolhead
The first time through this works as advertised, dropping into katapult bootloader by default until a new klipper firmware is loaded, but after that first time I found it a bit harder to force it back into bootloader for flashing. I found that in the Klipper 'scripts' subfolder, there is a flash_usb.py that you can write a py script with to get a usb device to enter bootloader, but was not able to mirror that behaviour for the UART interface for my stm32 chip, even after getting katapult on it. You've managed to solve both issues with one update to the katapult script.
I worked with flashtool.py for some time during bootloader source code modifying and discovered that this tool can't send separate command to exit from bootloader. I added parameter and method for this behavior. How do you think is this parameter useful for other people? So we can check every step. Send request to bootloader
-r, query it with-qand exit from it with-e.
I don't know how useful this functionality would be generally, I am really only using Katapult as a means to jump into the bootloader and flash klipper updates - I don't really have a need personally to query what's on the flash memory, and after flashing it automatically exits bootloader, so probably I wouldn't need a separate quit command either. That's not to say it wouldn't be useful to others who use Katapult in more complicated/interesting ways.