How to properly flash the microcontroller via command-line using the cube tool?

[ankes]

Hi,

This might be a bit of a noobish question but despite my best efforts at searching I could not find a suitable answer. This forum may also be the wrong place for this question but since it is related to the new "cube" Swiss knife tool I thought this might be the right place to start. Feel free to move this question elsewhere if appropriate.

I have a VS Code project that uses STM's extensions and bundles, and thus I can use "cube programmer" to invoke the STM32CubeProgrammer binary. In VS Code side I have a launch.json which allows me to build, flash and start debugging the application I've built on an STM32F0 series microcontroller. It works completely fine. Device appears in Windows, enumerates as a USB device, and everything just works as expected.

What I want to do now is execute the build and flash steps, and then instruct the MCU to begin executing the program. I tried to do this by invoking the "cube programmer" with the following litany:

 

cube programmer -c port=SWD mode=UR -d build/firmware.elf -v fast -hardRst -s

 

"build/firmware.elf" is where the binary gets output by the CMake build process. It uses a linker script during the build stage, and contains the assembly file "startup_stm32f042x6.s" so per my understanding it should be a fully-working binary with a "bootloader" that loads the program from flash to SRAM and runs it by invoking "main".

To my understanding, the command itself should connect to the MCU under reset, download the binary file, verify it, hard-reset the controller and then instruct the MCU to start from the default start address.

Alas, the flash is erased, the binary is programmed, the MCU is reset and started, and then... nothing. The device does not appear, does not enumerate, and in general seems dead.

When I compare my workflow with what the launch.json does then the only crucial difference is that it seems to wrap the binary file into something called "ST-LINK_GDB_server_a29668.srec". The file has exactly the same size as my binary. My guess is that it is somekind of a GDB-wrapper code around the binary but what exactly, I don't know. I also believe I should not use that if I want to flash a "release version" of my binary to the controller.

I must be missing something obvious here but what?

Also note: my end goal is to integrate this whole command as part of the VS Code's "tasks" system. Thus I can use things like "${command:st-stm32-ide-debug-launch.get-projects-binary-from-context1}" which I've seen floating around the forums, but I would like to know what exactly does this command do?

The BOOT pin of the MCU is pulled to GND.

[ankes]

An update on this matter.

I tried the exact same command as above but with the difference that I first "cd'd" into the "build" directory, and thus the command became

cube programmer -c port=SWD mode=UR -d firmware.elf -v fast -hardRst -s

With this command, the program is flashed and the application starts up immediately, without me needing to do anything else.

I thought that the problem might be somehow related to the option bytes of the MCU so I decided to give this command a try:

cube programmer -c port=SWD -ob displ

After a successful flash and run, and running this command I get a list of option bytes which indicate that everything should be fine.

If I flash from the "parent directory", and the MCU does not start, and I then issue the command to display the option bytes I see the same result as with the "successful" case but in addition to MCU suddenly starts executing and appears to work.

What on Earth is going on here?

[ankes]

I found out the problem. It is the "-s" switch that's now causing problems.

The ELF file I am flashing contains metadata which indicates the entry point to be 0x08002FD9. When I use the "-s" switch the programmer output shows that it tries to start executing from "0x08000000". Presumably this is the wrong starting address for this binary.

When I omit the "-s" switch altogether, and use a command like so

cube programmer -c port=SWD mode=UR -d build/firmware.elf -v fast -hardRst

then the application is flashed, verified, the MCU is reset, and runs without an issue.