Who is that?
One of the things I learned about over the past month was the existence of the STM32 “DFU” bootloader built into many of their MCUs (I’ve wanted to have something like that for years in the devices I’ve worked with):
This allows programming through the USB port as long as there is a “Boot0” pin which has a jumper to power like how it’s done on the Octopus board:
If you have that capability built into the controller board, you never have to worry about SD Cards again (and, for me, that’s a good thing).
STOP THE PRESSES
Before sending this reply off, I thought to take one last look at the BTT SKR Mini E3 V3 schematic after seeing that the ST32G0 has the DFU Bootloader built in and I realize that you could put the board into DFU mode and program it from a Raspberry Pi or Windows PC.
It looks like U2 (the STM32G0B1RCT6) pin 46 (marked "PA14+BOOT0) on the schematic above is also used as the SWD “SWCLK” line and goes to a pin J11, right beside 3.3V.
So, to put the board into DFU Mode, simply power down your system, jumper pins 3 & 4 of J11, power back up, connect your Raspberry Pi or Window PC and run DFU. When that’s done, power down, remove the jumper, power back up and Robert’s your mother’s brother.
2 Likes
Research in Motion - the Blackberry guys.
2 Likes
OK. Thank a lot for that information.
Anybody tried this solution?
If you wish, you can install canboot on your skr mini e3 v3 board: GitHub - Arksine/CanBoot: Can Bootloader for Klipper MCUs
I installed it on my v3 board. I find canboot to be more convenient, because I can then flash directly over USB, and I don’t have to mess with SD cards.
Be careful though - if a canboot install is not done correctly it can put the board in a state that would require reprogramming via SWD. (And thus require an “stlink” or similar device to fix the bootloader.)
Just for reference, these are the settings I used for my skr-e3-v3 canboot config:
In theory one would build canboot, then copy the resulting out/deployer.bin to a file named “firmware.bin” on the sdcard, boot the skr-e3-v3 with that sdcard. Since you’ve got a flaky sdcard - there’s unfortunately a risk that you get a bad flash that requires a recovery via SWD.
If it does succeed, though, you should see the skr-e3-v3 led flashing. Flashing Klipper can then be done via Klipper’s “make flash” command (eg, make flash FLASH_DEVICE=/dev/serial/by-id/...).
Caveat Emptor,
-Kevin
1 Like
Wouldn’t you still be able to do a DFU programming of the MCU?
Recovery via DFU is likely an option if one can access it. I have used SWD on my skr-e3-v3. I have not tested recovery via DFU on the skr-e3-v3.
Programming via SWD is annoying, but not particularly difficult. It just requires a few “dupont jumper wires” from the skr to an stlink or rpi running OpenOCD. I did not need to solder anything to use it.
There is a section on running OpenOCD on a rpi at Bootloaders - Klipper documentation .
-Kevin
1 Like
So I just tried many variations of your idea. Connecting the swclk pin to ground did nothing, connecting it to 3.3v did nothing (and I think this is what would be needed normally, the EBB36 with the STM32G0B1 hooks boot to 3v3 when putting into dfu mode) but nothing would work. Even tried different pins in case the pinout “1” pin was swapped around but still no dice.
I think the only options are the STLink or trying Canboot deployer.bin to overwrite the stock bootloader (and this still needs a functioning micro-sd card reader at least the first time.
You know what - I think I misread the schematic.
Could you try tying Pin 4 and Pin 1 together? That should bring SWCLK to a high level and put it in DFU mode when it’s powered up.
Sorry about that.
Yep, I tried that. SWCLK pulled high or low, I couldn’t get it into DFU mode.
Now, maybe there was just something else going on, I noticed after all my futzing around I couldn’t get the board to respond to klipper until I rebooted the pi, but I don’t think this would have affect DFU mode as each time I reset the SKR (with various combinations of power/gnd on the SWCLK) it would only ever show up as the ‘openmoko can adapter’ to an lsusb and would never show as a DFU device via dfu-util -l
How are you powering down? Are you also disconnecting the rPi when you are powering down?
For what it’s worth if someone doesn’t want a clone (which in my experience work fine, but updating firmware tends to be a little finicky, especially in Linux), you can break off the programmer from any nucleo board and use that. Nucleo ST-Link Interface | RadioShuttle Network Protocol
I had a nucleo lying around from like 10 years ago so I tried it out. Works great. Only caveat seems to be I don’t actually get any voltage on the vdd pin. But you can grab 3.3v off the JP1 jumper if you want to power a board directly.
I do think an stlink is a handy device to have if you’re going to be flashing a lot. Usually things are recoverable without it, but sometimes they’re not.
Now annoyingly the SKR Mini E3 V3 come at random with an STM32G0B0 or G0B1. Mine unfortuantely came with the G0B0, so I can’t use CAN. So I ordered the G0B1 off mouser and am going to give replacing it a shot (I am pretty good at SMD soldering so I’m not particularly concerned)
The reason this isn’t working is because the option bits in the CPU are set to ignore the boot0 pin
If you uncheck nBOOT_SEL, then pulling boot0 high should work like normal. Unfortunately you need to use an stlink to set that bit the first time. It might also be possible to flip the bits at run time, but without being able to upload and execute our own code, it’s a moot point
Interesting, thank you.
I thought setting the BOOT0 pin overrode the boot mode of the MCU.
It’s not well explained in:
Which I thought were the primary references for the STM32 boot modes.
This is the relevant table. The highlighted row is where we’re stuck with the nBOOT_SEL bit set. Note that the boot0 pin is ignored altogether in that state
Where is this table found? It’s not in the App Notes I referenced.
Thanx.
Hello everyone,
I’ve stumbled on this post while researching ability to flash firmware to SKR Mini E3 V3 via USB. I did exactly what @koconnor suggested and flashed CanBoot (which is awesome). But then I was unable to enter boot mode again because the firmware I used didn’t support that, so I just gave up and purchased the ST-Link v2 clone from amazon and after long trial and failures restored original firmware, flashed CanBoot again and installed klipper. Device costs a little less than 10 bucks.
Here’s the command for future reference:
openocd' -f openocd.cfg -c "init; reset halt; stm32g0x unlock 0; reset halt; program <path/to/firmware>.bin verify reset halt exit 0x08000000"
You will need latest OpenOCD from master because anything shipped with distros is too old and does not support the stm32g0 family.
What it does:
- unlocks flash memory to be writable
- resets couple of times
- flushes firmware starting at 0x08000000 address
- verifies it
For what it’s worth I find doing this once and getting proper bootloader saves me a lot of time and removes the flaky sd-card firmware flashing mechanism
Good luck
1 Like
STM32G0B1 datasheet (G0B0 has essentially the same table as well)
https://www.st.com/resource/en/datasheet/stm32g0b1kc.pdf
The reference manual also has a similar table https://www.st.com/resource/en/reference_manual/dm00371828-stm32g0x1-advanced-arm-based-32-bit-mcus-stmicroelectronics.pdf
1 Like