Mutable dev environment - workflow questions

Hi! I have some workflow questions, but would also like to use this thread more broadly to exchange workflow questions, tweaks and tips when using the dev environment, or other ways of working with this and similar code in general.

To give some context, I’m running Windows, using VS Code, and uploading from its built-in console to a STM32F407 dev board; there were some hitches getting started with this one, which I’ll try to write more about later if I can manage to retrace my steps.

In particular I’d be curious to know:

  • STM’s windows tools only need a few seconds to connect and upload, compared to ~30s or so through OpenOCD currently. I’ve tried swapping “upload-jtag” for “upload-jtag-no-erase” in the makefile and got mostly errors. Is there anything else I can try to speed up the upload process?

  • Starting and stopping both debug server and client manually between uploading new builds gets tedious rather quickly. Is there some sort of one-stop script I can run to launch both them both at once, or even better upload and launch straight into debug?

  • I also found the “image-…” commands interesting. I’m guessing this is to dump the current state or RAM to a file? What would I be able to do with this file? Are there tools I can use to examine it?

1 Like

Interesting. The mass erase can take a lot of time on parts with 1M of Flash or more. There’s one command (with the _erase_first) suffix that might be faster.

You can directly keep an openocd prompt open, and launch the commands (reset halt, flash write_image erase bin.bin 0x08000000) from there.

I use it mostly to troubleshoot settings saving code, or to troubleshoot modules with problems linked to corrupted flash memory. I use an hexadecimal editor to inspect the contents of this file.

1 Like

Using erase_first brought it down to 12s so much better. I’ll have to delve into working with the openocd command line some more soon I guess. Thanks for the help!