2021-08-04 04:52 PM
When flashing a bin file to a blank/erased STM32G070 the --reset option does not consistently reset the processor after flash.
The first couple times I did this it worked. Now it is not.
A snippet of the output from a failed example using the command 'st-flash --reset --debug write foo.bin 0x08000000' is below:
2021-08-04T16:40:02 DEBUG usb.c: r_idx (16) = 0x81000000
2021-08-04T16:40:02 DEBUG common.c: *** stlink_jtag_reset ***
2021-08-04T16:40:02 DEBUG common.c: *** stlink_reset ***
2021-08-04T16:40:02 WARN usb.c: NRST is not connected
2021-08-04T16:40:02 DEBUG usb.c: Using reset through SYSRESETREQ
2021-08-04T16:40:02 DEBUG common.c: *** stlink_soft_reset ***
2021-08-04T16:40:02 DEBUG common.c: *** stlink_write_debug32 0xa05f0003 to 0xe000edf0
2021-08-04T16:40:02 DEBUG common.c: *** stlink_write_debug32 0x01000500 to 0xe000edfc
2021-08-04T16:40:02 DEBUG common.c: *** stlink_read_debug32 0x01030003 at 0xe000edf0
2021-08-04T16:40:02 DEBUG common.c: *** stlink_write_debug32 0x05fa0004 to 0xe000ed0c
2021-08-04T16:40:02 DEBUG common.c: *** stlink_read_debug32 0x03000001 at 0xe000edf0
2021-08-04T16:40:02 DEBUG common.c: *** stlink_read_debug32 0x01000001 at 0xe000edf0
2021-08-04T16:40:02 DEBUG common.c: *** stlink_write_debug32 0x0000001f to 0xe000ed30
2021-08-04T16:40:02 DEBUG common.c: *** stlink_exit_debug_mode ***
2021-08-04T16:40:02 DEBUG common.c: *** stlink_write_debug32 0xa05f0000 to 0xe000edf0
2021-08-04T16:40:02 DEBUG common.c: *** stlink_close ***
Setup:
2021-08-04 05:12 PM
Perhaps use STM32CubeProgrammer CLI instead, or report the issue to the people who make st-flash.
2021-08-04 05:45 PM
Newer STM32 need to be power cycled if programmed from blank, it maps boot from ROM if it detects it is empty and that gets latched in a way that a reset doesn't clear.
2021-08-06 09:50 AM
Is this documented anywhwere? I've searched for this, but couldn't find it.