First of all: I'm quite recently involved in the STM32 ecosystem. Due to good experiences with commandline tools for TI Cortex-M families, I'm seeking for comparable solutions to flash a device.
A few weeks ago I found dfu_commandline_pack. But that's quite outdated and lacks compatibility with recent intel hex format files. I ended up by using resources of the CubeProgrammer package. Its STM32_Programmer_CLI is a really powerful and versatile tool. So I started to strip all that is not needed in plain commandline usage.
But... on a KDE system (including Qt-libraries) I still need files left in the lib folder summing up to a few MB (while the unstripped lib folder contains approx. 65 MB. Then I tried to use it on a non KDE-System, and now way more library files must be included. Otherwise STM32_Programmer_CLI quits after start. I end up with 50 MB (where libicudate.so eats up 24 MB).
It's my goal to supply customers with a compact (mailable) tool for flashing over USB.
It seems that the only way is to strip down features in STM32_Programmer_CLI in order to eliminate quits due to missing libraries.
Any hints regarding this? Or should I use another tool? of course, any solution should include a variant executable on Windows.
>>Any hints regarding this?
Supposing you don't want to write DLLs or use URB / IOCTL on to the USB Stack, may be there are lower-friction approaches?
Could you have the device come up as a CDC or MSC type device, the former you can open as a COM/TTY, the latter you can drag-n-drop files too.
Got to imagine there are free-standing USB DFU tools if you dig a little.
Pick your battles..