Printer Model: Voron 0.2
MCU / Printerboard: Custom STM32F042 toolboard
Host / SBC: Intel NUC running Debian
klippy.log: Not running yet - firmware won’t boot at all
Describe your issue:
I’ve designed and made a custom toolboard for the Voron 0.2 based on an STM32F042G6U6TR MCU, which I’d love to share to the community once it’s up and running.
With this MCU, I’m able to flash it via USB by putting it into DFU mode when booting up (pulling the BOOT pin high), then using STM32CubeProgrammer on my main Windows PC to program it. This software detects and can program and verify the chip, no problems, so I know the USB connection is working.
I understand that this method of flashing via DFU / USB does not involve a “bootloader” - the MCU functionality for this seems to exist in ROM, and continues working even if I erase the entire flash memory.
So, I compile the Klipper firmware with the appropriate “no bootloader” setting, as opposed to an 8 or 16kB bootloader. I program the resulting klipper.bin file onto the MCU at address 0x0800000, which I believe is the beginning of the program space.
But then, when I go to test out booting up the board / MCU, expecting it to show up as a USB serial device as I initially test this on Windows, I hear the USB sound but get a “USB device not recognized” error.
And then trying plugging the programmed board into my Intel NUC with Debian, which is running the Klipper host for all of my printers, the new board also does not show up in a ls -l /dev/serial/by-id/
I’ve tried various things with no success, including:
Setting the compiled Klipper firmware, via its menuconfig, to switch a certain pin on on bootup, so I can see if it comes on correctly - it doesn’t. So the problem isn’t just with the USB connection.
Downgrading Klipper a couple of versions, in case there was a recent bug.
Trying instead using an 8kB bootloader, and setting the Klipper menuconfig option appropriately and programming the firmware now to 0x08002000, and also putting a bootloader at address 0x0800000 - the “STM32F103 with stm32duino bootloader” that I found in the Klipper bootloader instructions. Admittedly this is intended for a different STM32, but I’m not sure what one to try using for my STM32F042. When doing this, there was no USB activity - not even an error.
Different USB cable and port
Setting the clock reference to “internal clock” in menuconfig, as opposed to the 8MHz crystal setting I was using as that’s what I’ve used on my board.
Setting the communication interface to the other available USB pin option, and then also to “USB to CAN bus bridge”. Interestingly, these alternate options meant that when plugging my board in to Windows, it no longer gets any kind of USB activity, not even the “USB device not recognized” error I was getting before.
Switching off most of the options under “optional features (to reduce code size)”, which I had to do anyway to make the firmware fit into the 32kB flash that the MCU has.
Can anyone spot what I’m doing wrong? Help is much appreciated
You haven’t provided enough information to provide pointers as to your issues.
What is your process for putting your board’s MCU into DFU mode and then programming it? Explain in detail and provide screenshots to show what’s happening. You should be using lsusbto verify that the MCU is in DFU mode. What is the DFU-UTIL command that you’re using to burn the firmware into the MCU?
What is the hardware you’re using to program the MCU using STM32CubePGM?
Thanks for the help and sorry for my lack of info!
I don’t think that the programming of the MCU is the issue because STM32CubeProgrammer reads back and verifies the contents of the flash memory after programming, but here are my steps:
I have my board plugged via USB straight from the STM32’s D-/D+ pins into my PC’s USB hub (I also tried directly into the PC when trying to boot the board). Then while holding the BOOT button on my board, which pulls the BOOT/PB8 pin high, I press the reset button. This puts it into DFU mode.
STM32CubeProgrammer sees the board and is happy to connect to it.
I guess, MCU would boot from zero address and expect the bootloader here (like katapult), and this bootloader can boot things from 8kb offset.
If you flash Klipper without a bootloader, it should be flashed from the start (and compiled this way).
Okay, I guess I should have been more specific but you really need to volunteer up front as much information as possible and make it easy to understand. Please don’t provide multiple posts for each question as that makes it harder to follow what’s going on.
Could you provide us with:
What is the “PC” that you’re using? What OS is it running, what version of Klipper and how did you install Klipper?
What was the Klipper build process you are using and what are the results? What are the options you’ve selected? Ideally include a screenshot of the make menuconfig that you’re using along with the final result of make (which will display any errors). I’m asking because the STM32F042### only has a maximum 32kB of Flash which can make it a challenge to create a working Klipper firmware image.
Could you provide a complete schematic of your PCB? I’m looking to see actual USB connection used for both programming and running Klipper (not just “The programming hardware is just a USB cable straight into the STM32’s D-/D+ pins.“). For example, if you have a USB C connection, how are you setting the CC# pins (if they’re not correct and you’re plugging into a USB 3.0 connection the device won’t be properly recognized). It’s also customary (and recommended) to drive an LED from one of the MCU’s pins for status information - this is a great way to determine whether or not Klipper is loaded properly and is running.
Have you tried any of the more traditional methods of loading Klipper? This is using dfu-util, using the programming option in KIAUH or using flash_tool as set out in Arksine’s instructions: GitHub - Arksine/katapult: Configurable bootloader for Klipper
Is anything happening during the Klipper build process, programming operations that seems unusual or didn’t work the way you expected it to?
I’m sure I’m forgetting to request other information but this is a good start.
Again, please provide as much information as clearly as possible.
Just got it working - but not before removing every component not completely necessary for the STM32 to function from my PCB in order to rule everything out
The solution was that I needed to select USB on pins PA9/PA10 in Klipper’s make menuconfig. I know I said I’d tried that and it still didn’t show up on Windows when running and connected via USB. Well, actually it does show up if you’re watching Device Manager, which I had been checking during a lot of my troubleshooting but obviously not for that exact test, because I had been expecting Windows to make the USB-connected sound if the Klipper-running MCU connects as a COM port, as it does for every other USB device I’ve ever connected including COM ports. But, it seems that when a Klipper-running MCU connects as a COM port, Windows does not make the sound. Anyway, my mistake.
The solution of setting the USB pins to PA9/PA10 was un-obvious because the STM32F042 datasheet lists that USB_DM and USB_DP correspond to PA11 and PA12, and then only in a footnote notes that PA11/12 “can” be remapped to PA9/10 (which confusingly share the same pin numbers) on the 28- and 20-pin variants of the chip - implying that this is not the default option.
I’d go so far as to suggest that Klipper’s make menuconfig should include a note when selecting the USB pins for STM32F042, indicating that for the 28- and 20-pin variants of the chip, you have to select pins PA9/10.
EDIT: I suppose toolboards with only the extruder motor attached are a relatively recent phenomenon, so maybe no one else has tried an only 28-pin STM32F042 with Klipper yet.
