rusefi.com

At some point in the future we will have more boards without ST link. While programming via SWD is an option, the better way to go is using DFU feature of stm chips.

Using discovery board you can play with it if via microUSB cable you put a jumper between BOOT0 and VDD pins.

There are at least two options to upload the .dfu file
1) http://www.st.com/web/en/catalog/tools/FM147/CL1794/SC961/SS1533/PF257916 (please note that version 3.0.4 has a known defect, version 3.0.3 has worked for me)
2) http://dfu-util.sourceforge.net/

Now, here is where I need help: you need .dfu files for this to work. The ST bundle provides a GUI tool to convert a .hex into a .dfu, but I need a command-line tool for the build server. Looks like objcopy and dfu-suffix.exe should do the job, but I am failing to get this functioning - my command-line generated .dfu file seems to be invalid. See https://svn.code.sf.net/p/rusefi/code/trunk/firmware/temp.bat

Update: see also https://github.com/rusefi/rusefi/issues/147
Update: complete step by step usage instruction https://rusefi.com/forum/viewtopic.php?f=5&t=817&p=31229#p31229

how do you know the dfu file is bad?
just tried that command from your .bat file against my rusefi.elf (dated Jan. 19), got rusefi.dfu with the file size exactly as rusefi.bin - these files could easily be the same but with various suffixes…

Just in case you are interested, I get that rusefi.bin from rusefi.hex using the following command:
arm-none-eabi-objcopy -I ihex -O binary rusefi.hex rusefi.bin
and then I flash the board:
~/Development/embedded/tools/stlink/st-flash write rusefi.bin 0x08000000

I know that the .dfu I get from the ST File Manager GUI I can flash into my stm chip using both the ST dfu and dfu-util

The dfu I get from temp.bat would not work with both SD dfu and dfu-util

try using key -I ihex

puff wrote:try using key -I ihex

That's an idea or the solution? Do you have Windows to try all this? This would help.

that was an idea. i don't have windows to try it. i seem to get troubles converting from hex to bin (I need .bin to flash the board). as far as i recall, the resulting bin was huge and invalid. then i used that -I key to get the proper bin file.

Some progress has happened in this area today under https://github.com/rusefi/rusefi/issues/147 - we now include dfu files into https://rusefi.com/build_server/rusefi_bundle.zip

At the moment this is only a nice to have 3rd option but maybe this would become more used in the future.

All in all, what does it mean? If I take a blank stm chip, I would need ST Link just once to upload a bootloader, and then I'd be able to upgrade the firmware using its USB port? Do you have a step-by-step guide?

Nope, default bootliader supports usb programming.

Complete instruction:
-1) on nucleo144 board, boot0 is in top-left corner
0) download STSW-STM32080 DfuSe USB device firmware upgrade tool https://www.st.com/en/development-tools/stsw-stm32080.html or https://sourceforge.net/projects/dfu-util/ if not on Windows
1) put a jumper on boot0+vdd pins
2) reset mcu
3) use command

DfuSeCommand.exe -c -d --fn rusefi.dfu

from flash_dfu.bat to flash say srm32f4 using its own usb connection (microusb in case of discovery)
4) once complete, remove jumper and reset again

thx! it's good to know you don't have to have st-link in case you need just to install firmware, without debugging.

Successfully tested DFU programming on linux.
'-a 0' specifies alt=0 (discovery appears as 4 dfu devices, alt 0 is internal flash)

'-D rusefi_release.dfu' for download (dfu is from device perspective?) and file path

'-R' is supposed to reset after flash, did not seem to do anything for me

Using dfu-util 0.9 on Arch Linux

Thank you!
Just did it! (took half a minute though)
st-link seemed to work way faster.

We now have our own DFU uploader https://github.com/rusefi/dfu_java

This opens the door for DFU uploader in rusEFI Android application.