stlink: STM32G030: Reset not working properly

Hi, thanks a lot for the very good tool. I’m using st-flash in a bash script (Debian GNU/Linux) with a cheap ST-LINK V2 USB programmer, to program and then run the firmware on the MCU:

1. program STM32G030 target: if already programmed, issue an erase then program MCU again
2. write options to secure the device and issue a NRST to start the firmware.

I’ve tried both version 1.7.0 distributed with Debian and last version 1.7.0-201-g254a525 from github. SWD connection including NRST Issue commands:

st-flash --connect-under-reset write $file 0x08000000    (program)
in case of error: 
    st-flash --connect-under-reset write /tmp/rdp0.bin 0x1fff7800    (mass erase)
    st-flash --connect-under-reset write $file 0x08000000 (program)
st-flash --reset --connect-under-reset write /tmp/rdp1.bin 0x1fff7800   (protect flash)

What I can see, using the oscilloscope, is that SOMETIMES at the end of programming a long reset (NRST) is issued and the firmware starts correctly, but the successive command to protect flash stops the firmware, issue some resets, but firmware does not start. Firmware starts only if the NRST reset is pull down without any SWD data exchange. If, at the end of programming and NRST is pull down, during SWD data exchange, firmware will not start.

Commandline output for the last write (flash protection):

st-flash 1.7.0-201-g254a525
Failed to parse flash type or unrecognized flash type
2022-07-25T08:59:22 WARN common.c: NRST is not connected        (but NRST is connected!!)
2022-07-25T08:59:22 INFO common.c: STM32G03x_G04x: 8 KiB SRAM, 32 KiB flash in at least 2 KiB pages.
file /tmp/rdp1.bin md5 checksum: 3ef145d53b47fbc453262a26dc6dd0c, stlink checksum: 0x000003be
2022-07-25T08:59:22 WARN option_bytes.c: Writing option bytes 0xdfffe1ff to 0x1fff7800
2022-07-25T08:59:22 INFO option_bytes.c: Wrote 4 option bytes to 0x1fff7800!
2022-07-25T08:59:22 INFO common.c: Go to Thumb mode

Using the command st-flash --debug reset does not reset anything: Command output is:

st-flash 1.7.0
2022-07-25T09:10:15 DEBUG common.c: *** looking up stlink version
2022-07-25T09:10:15 DEBUG common.c: st vid         = 0x0483 (expect 0x0483)
2022-07-25T09:10:15 DEBUG common.c: stlink pid     = 0x3748
2022-07-25T09:10:15 DEBUG common.c: stlink version = 0x2
2022-07-25T09:10:15 DEBUG common.c: jtag version   = 0x27
2022-07-25T09:10:15 DEBUG common.c: swim version   = 0x7
2022-07-25T09:10:15 DEBUG common.c: stlink current mode: mass
2022-07-25T09:10:15 DEBUG usb.c: JTAG/SWD freq set to 0
2022-07-25T09:10:15 DEBUG common.c: stlink current mode: mass
2022-07-25T09:10:15 DEBUG common.c: *** stlink_enter_swd_mode ***
2022-07-25T09:10:15 DEBUG common.c: Loading device parameters....
2022-07-25T09:10:15 DEBUG common.c: *** stlink_core_id ***
2022-07-25T09:10:15 DEBUG common.c: core_id = 0x0bc11477
2022-07-25T09:10:15 DEBUG read_write.c: *** stlink_read_debug32 0x410cc601 at 0xe000ed00
2022-07-25T09:10:15 DEBUG read_write.c: *** stlink_read_debug32 0x10016466 at 0x40015800
2022-07-25T09:10:15 WARN common.c: unknown chip id! 0x466

I expect that:

1. –reset parameter lead to a SWD reset command, and finally NRST is pull down for about 100us without issuing new SWD commands
2. reset command do the same as point 1. Unknown chip ip, ok, but pull down NRST anyway!

Thanks a lot!

The following picture shows that, after firmware programming (with --connect-under-reset parameter), st-link issue a NRST reset (yellow trace) followed by NO SWD commands (green trace): the firmware starts (cyan trace).

After MCU protection (with --reset --connect-under-reset parameters), NRST is pulled down (yellow trace) but followed by SWD commands (green trace): firmware on MCU did not start.