To follow up - there is a way which resets just fine:
~/.platformio/packages/tool-openocd/bin/openocd -d2 -s /Users/jcw/.platformio/packages/tool-openocd/scripts -f board/st_nucleo_l4.cfg -c "program {.pio/build/blink/firmware.elf} verify reset; shutdown;"
The PIO command is different though, it does not use that board file:
openocd -d2 -s /Users/jcw/.platformio/packages/tool-openocd/scripts -f interface/stlink.cfg -c "transport select hla_swd" -f target/stm32l4x.cfg -c "program {.pio/build/blink/firmware.elf} verify reset; shutdown;"
Note the different files use. My hunch is that the order of files & commands matters, and that what I’ve tried manually doesn’t do the right thing, The board/st_nucleo_l4.cfg
file includes the above two -f
files, I think - but with some subtle differences.
Sooo … my conclusion so far is that the OpenOCD command constructed by PIO is good enough for normal uploads, but that a better choice would be to select the board file already present in the OpenOCD scripts. Then uploads will work regardless of the state of the µC.
Update - I’m not 100% certain of the above. Still trying to understand the different scenarios, but when I put the µC is standby mode, it seems to work, i.e. does a hard reset (whereas the PIO default doesn’t). FWIW, the board/st_nucleo_l4.cfg
contents is as follows:
# Should work with all STM32L4 Nucleo Dev Boards.
# http://www.st.com/en/evaluation-tools/stm32-mcu-nucleo.html
source [find interface/stlink.cfg]
transport select hla_swd
source [find target/stm32l4x.cfg]
# use hardware reset
reset_config srst_only srst_nogate