Firmware to Enable DFU Mode in the BTT SKR Mini E3 V3

Over two years ago, we had this discussion regarding using DFU Mode with the BTT SKR Mini E3 V3 and I fear that my understanding of what was required was in error:

The BTT SKR Mini E3 V3 was the first board I worked with Klipper with and, while I liked working with it, I always hated having to use an SD Card for updating the firmware. This was confirmed when I built my Voron 2.4 and used DFU mode with the Octopus board that was used with it.

Based on my limited understanding of how DFU worked, I thought that it would be available for all boards that had a MCU that had that capability (and I asserted that incorrectly in the referenced post above) - to have it available the option bytes in the MCU have to be set appropriately.

For the STM32G0B1, used in the BTT SKR Mini E3 V3, that meant the nBOOT_SEL bit had to be reset (it’s set at the factory).

To test this out, I first reset the bit using an ST-Link and then wrote a little bit of firmware can be loaded onto an SD Card and will reset the nBOOT_SEL bit of the BTT SKR Mini E3 V3’s STM32G0B1 MCU.

After doing this, to enable DFU Mode, the SWCLK pin of the SWD header on the BTT SKR Mini E3 V3 will have to be tied high:

To do this, I made a little jumper connector using a 5x1 Dupont connector installed like:

By doing this, you can now update the firmware on the MCU built into the BTT SKR Mini E3 V3 without having to use an SD Card.

I’ve documented the procedures as well as put the bin file for the firmware here:

Next steps is to build a little board that will allow me to set the SWCLK line high and hit reset so I don’t have to open up the printer to enable DFU Mode - I would have that done now, but I’m waiting on parts from Digi-Key. Hopefully I’ll show the design here early next week.

NOTE: This has ONLY been tested and verified on the BTT SKR Mini E3 V3 and it will most likely not work on any other system and could brick it. When I say “verified”, I have checked the option bytes in the MCU and made sure that only the nBOOT_SET bit was changed.

If anybody wants to do this for another board, I’ll give pointers but, chances are, I won’t have the board to verify how the code works and I really don’t have the time to hold somebody’s hand through the process.

Interesting. Is it not possible to just use Katapult to achieve the same?

Directly - no. I had a discussion with @Arksine on this. The user would have to first install Deployer and then use it to install Katapult.

Admittedly, the solutions are basically the same except that with using my code the user has DFU Mode (or some other method of Flashing the MCU) available to them, which is something @Arksine recommends in the Deployer section of the Katapult GitHub page:

This code is part of the effort to get my custom boards functional test up and running - Run it to provide DFU Mode without having to purchase pre-Flashed chips.

Thanks.
This means that the “casual user” would simply build and flash the deployer.bin using the SD card method and could also flash without physically accessing the board.
The only “downside” is the inability to use DFU if it becomes necessary.

No, they will always need to physically access the board - even if they are using Katapult, they will need to access the reset button (push twice) to make Katapult active.

I’ve got an idea on how to make that easier - stay tuned.