Last October I created an experimental PR adding support for SD Card updates to Katapult. While I didn’t mark it as a draft, its purpose was intended to gauge interest in this feature, and if there was sufficient interest to get some additional testers. That said, I did not make an announcement beyond the PR and I put it on hold due to time constraints.
I would like to get feedback on it now from those willing to participate. Unlike your typical SD Card bootloader, Katapult does not attempt to detect the presence of “firmware.bin” on every boot, you must enter the bootloader (either by double reset, a button, or using flashtool.py with the -r option). Once Katapult has entered the bootloader it will attempt to initialize the SD Card and look for the firmware file. If firmware is detected it will write it to flash and reset to the application (if the status LED is enabled it will blink rapidly until the process is finished). If no SD Card is detected or no firmware file is found then Katapult will enter command mode, listening for requests from the command interface. SD Card support is enabled and configured though build options, it remains possible to build a minimal Katapult under 4KiB with the right toolkit version (IIRC arm tools released between 2019 and 2021 will do it).
There are a few reasons Katapult doesn’t attempt to initialize the SD Card on boot and use it as a trigger to enter the bootloader:
It would add significant delay to the reset procedure. It can take 300+ ms to initialize an SD Card.
Doesn’t work well with double reset. We would need to avoid a user attempting a double reset while the SD Card is being initialized.
Avoids changing the SD Card’s state under normal use. While Katapult does attempt to reset the card it is best for the card to be in its power-up state for applications that use it.
Does SD support for Katapult make sense? I’d welcome feedback on why it should be included, or alternatively on why it should be excluded.
If the feedback is positive, I would like to do as much testing as possible. I have done my own testing, however I don’t have access every device supported by Katapult. Likewise, it would be good to test as many SD Card variants as possible. Finally its important to make sure there are no regressions with the primary upload method.
In my opinion, firmware updates from an SD card in its current form are not very useful, if not completely useless. I use Katapult because my printer doesn’t have any accessible buttons on any of the boards. They exist, but you have to disassemble everything to reach them. In the factory setup, firmware was updated via an SD card, which isn’t convenient, but it allowed you to reflash in case of an error. You could also tell whether the firmware update occurred by the changed file extension.
After my first attempt to use Katapult, I had to disassemble the printer and restore the factory bootloader; if Katapult had offered this option at the time, it wouldn’t have been necessary. If, for some reason, Klipper fails to start, I won’t be able to access the bootloader without pressing buttons. If, in addition to firmware updates via USB/serial, there were an option to insert an SD card to change the firmware, I would update Katapult. In my view, firmware updates from an SD card serve as a backup method and are also useful for those who aren’t very familiar with USB/serial processes. It’s a fairly standard behavior – if an SD card is present, the system looks for a file with a reserved name on it and uses that file.
300 ms is nothing compared to the printer’s startup time. It’s better to wait 300 ms than to spend 30 minutes disassembling the printer, connecting the ST-Link, and remembering how to use it, etc.
Thanks for the feedback! To start I would like to summarize what I believe your position is, because I think we generally agree.
SD Card flashing isn’t useful as a primary flash method. 100% agree with this observation.
SD Card flashing IS useful as a recovery or bench testing feature. That is my gut feeling and why I started down this road.
With regard to the 300+ ms delay, the issue isn’t that the user would have to wait this amount of time. If the user has double reset enabled, SD Card initialization could not start until after the 500ms reset period. Even then, if the user is late on the reset then it would occur during SD Card init, which isn’t ideal. So total reset time is going to be over 800ms. It should be noted that 300 ms SD Card init time is just what I would consider typical. Depending on the SD Card it can take much longer.
A long delay after a reset can create issues with usb device re-enumeration. This was (still is?) a problem with the smoothieware bootloader on SKR 1.3 boards. Klipper would request a reset via FIRMWARE_RESTART, the device would spend too long in the bootloader, leading to an issue where the device failed to re-enumerate. IIRC a power cycle is necessary to clear the issue. I will mention that this issue wouldn’t affect Klipper with Katapult, because Klipper explicitly requests that Katapult skip all bootentry checks before resetting the MCU.
It seems that your primary concern here is that requiring manual bootloader entry would also require that you disassemble your printer to reach the board. For many printers this would be necessary anyway to reach the SD Card slot, so I’m going to assume you have an SD Card slot that is accessible from outside of the printer.
There are a couple of options that can get around this problem. The most obvious would be to wire a switch/button to the board and configure Katapult’s button option. Of course this requires extra hardware, wiring, etc which isn’t ideal for many.
Alternatively, most boards should have an “SD Card Detect” pin connected to a GPIO. That GPIO could be configured as Katapult’s “entry button”, which should cause Katapult to enter the bootloader when the SD Card is present on boot. Katapult would then look for firmware.bin (the file name is configurable, that is the default) and flash if its present. I’ll test this on one of my boards to see how it works.
Absolutely true, if, of course, updating via an SD card isn’t the only option.
Absolutely true.
Perhaps it’s possible to emulate a boot button press. For instance, a short initial press could reset the microcontroller, and the bootloader at startup would check whether the button is pressed and held for 1 second. I don’t know how a double reset works—just some thoughts.
Yes, on my printer, the SD card slot is accessible without disassembly, and as far as I know, this is the case for all Kingroon printers. When you consider what is more commonly found on a printer’s case—a button to restart the microcontroller or an SD card slot for firmware updates—it turns out that the SD card slot is more likely to be available. I could add a button, of course; there’s no problem with that. But it’s more complicated than simply using the factory method of firmware update via SD card. It would be great if Katapult could also function as the factory bootloader, just in case I accidentally flash something wrong.
A little off-topic regarding the utility flashtool.py: with many utilities (stm32flash, dfu-util, open-ocd), you must explicitly specify the firmware file and the parameter for writing the firmware. flashtool.py behaves strangely—it takes the firmware file from the klipper directory, which at that moment might contain firmware for an entirely different microcontroller. In such a case, I would most likely lose the ability to access the bootloader.
