search

stlink-org / stlink

Open source STM32 MCU programming toolset
BSD 3-Clause "New" or "Revised" License
4.35k stars 1.23k forks source link

STM32G030: Reset not working properly #1260

Closed CreasolTech closed 12 months ago

CreasolTech commented 2 years ago

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). reset_after_firmware_programming

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. reset_after_mcu_protection

CreasolTech commented 2 years ago

Hi, I've checked updating the st-link software to use only HARD reset by NRST, but I always see that the ST-LINK V2 clone dongle sends NRST pulse and then send other commands to the SWD: the result is that I cannot get the firmware starting after MCU being programmed. What I'd like to do is to connect the SWD probes to the board, program, secure MCU and then start the firmware, so it's possible to program and immediately test the board. Should I use another kind of ST-LINK dongle (preferibly with 3.3V power supply)? Any suggestion is welcome. Thanks. Paolo

CreasolTech commented 2 years ago

Just tried the command st-flash --debug --connect-under-reset reset using a NUCLEO board, and the problem is always the same: a NRST reset is sent during some SWD command, so the firmware in the MCU did not start. immagine Cyan trace is NRST, and yellow trace is SWDIO. Please note the warning where st-flash think that NRST is not connected (but it's connected)!

pi@creasol:~ $ st-flash --debug --connect-under-reset reset
st-flash 1.7.0-201-g254a525
Failed to parse flash type or unrecognized flash type
2022-08-05T12:17:37 DEBUG common.c: *** looking up stlink version
2022-08-05T12:17:37 DEBUG common.c: st vid         = 0x0483 (expect 0x0483)
2022-08-05T12:17:37 DEBUG common.c: stlink pid     = 0x374b
2022-08-05T12:17:37 DEBUG common.c: stlink version = 0x2
2022-08-05T12:17:37 DEBUG common.c: jtag version   = 0x27
2022-08-05T12:17:37 DEBUG common.c: swim version   = 0x1b
2022-08-05T12:17:37 DEBUG common.c: stlink current mode: mass
2022-08-05T12:17:37 DEBUG usb.c: JTAG/SWD freq set to 0
2022-08-05T12:17:37 DEBUG common.c: *** stlink_enter_swd_mode ***
2022-08-05T12:17:37 DEBUG common.c: *** stlink_jtag_reset 0 ***
2022-08-05T12:17:37 DEBUG common.c: *** stlink_jtag_reset 1 ***
2022-08-05T12:17:37 DEBUG read_write.c: *** stlink_read_debug32 0x03030003 at 0xe000edf0
2022-08-05T12:17:37 DEBUG common.c: *** stlink_soft_reset (halt) ***
2022-08-05T12:17:37 DEBUG read_write.c: *** stlink_write_debug32 0xa05f0003 to 0xe000edf0
2022-08-05T12:17:37 DEBUG read_write.c: *** stlink_write_debug32 0x01000501 to 0xe000edfc
2022-08-05T12:17:37 DEBUG read_write.c: *** stlink_write_debug32 0x00000008 to 0xe000ed30
2022-08-05T12:17:37 DEBUG read_write.c: *** stlink_read_debug32 0x00030003 at 0xe000edf0
2022-08-05T12:17:37 DEBUG read_write.c: *** stlink_write_debug32 0x05fa0004 to 0xe000ed0c
2022-08-05T12:17:37 DEBUG read_write.c: *** stlink_read_debug32 0x03030003 at 0xe000edf0
2022-08-05T12:17:37 DEBUG read_write.c: *** stlink_read_debug32 0x00030003 at 0xe000edf0
2022-08-05T12:17:37 DEBUG read_write.c: *** stlink_read_debug32 0x00000009 at 0xe000ed30
2022-08-05T12:17:37 DEBUG read_write.c: *** stlink_write_debug32 0x0000001f to 0xe000ed30
2022-08-05T12:17:37 DEBUG common.c: stlink current mode: debug (jtag or swd)
2022-08-05T12:17:37 DEBUG common.c: Loading device parameters....
2022-08-05T12:17:37 DEBUG common.c: *** stlink_core_id ***
2022-08-05T12:17:37 DEBUG common.c: core_id = 0x0bc11477
2022-08-05T12:17:37 DEBUG read_write.c: *** stlink_read_debug32 0x410cc601 at 0xe000ed00
2022-08-05T12:17:37 DEBUG read_write.c: *** stlink_read_debug32 0x10016466 at 0x40015800
2022-08-05T12:17:37 DEBUG chipid.c: detected chip_id parameters

2022-08-05T12:17:37 DEBUG chipid.c: # Device Type: STM32G03x_G04x
2022-08-05T12:17:37 DEBUG chipid.c: # Reference Manual: RM0444           // also RM454
2022-08-05T12:17:37 DEBUG chipid.c: #
2022-08-05T12:17:37 DEBUG chipid.c: chip_id 0x466
2022-08-05T12:17:37 DEBUG chipid.c: flash_type 5
2022-08-05T12:17:37 DEBUG chipid.c: flash_size_reg 0x1fff75e0
2022-08-05T12:17:37 DEBUG chipid.c: flash_pagesize 0x800
2022-08-05T12:17:37 DEBUG chipid.c: sram_size 0x2000
2022-08-05T12:17:37 DEBUG chipid.c: bootrom_base 0x1fff0000
2022-08-05T12:17:37 DEBUG chipid.c: bootrom_size 0x2000
2022-08-05T12:17:37 DEBUG chipid.c: option_base 0x1fff7800
2022-08-05T12:17:37 DEBUG chipid.c: option_size 0x4
2022-08-05T12:17:37 DEBUG chipid.c: flags 0

2022-08-05T12:17:37 DEBUG read_write.c: *** stlink_read_debug32 0xffff0020 at 0x1fff75e0
2022-08-05T12:17:37 INFO common.c: STM32G03x_G04x: 8 KiB SRAM, 32 KiB flash in at least 2 KiB pages.
2022-08-05T12:17:37 DEBUG common.c: *** stlink_force_debug_mode ***
2022-08-05T12:17:37 DEBUG read_write.c: *** stlink_read_debug32 0000000000 at 0x40015808
2022-08-05T12:17:37 DEBUG read_write.c: *** stlink_write_debug32 0x00001800 to 0x40015808
2022-08-05T12:17:37 DEBUG common.c: *** stlink_status ***
2022-08-05T12:17:37 DEBUG usb.c: core status: 00030003
2022-08-05T12:17:37 DEBUG common.c:   core status: halted
2022-08-05T12:17:37 DEBUG common.c: *** stlink_reset ***
2022-08-05T12:17:37 DEBUG read_write.c: *** stlink_read_debug32 0x00030003 at 0xe000edf0
2022-08-05T12:17:37 DEBUG common.c: *** stlink_jtag_reset 0 ***
2022-08-05T12:17:37 DEBUG common.c: *** stlink_jtag_reset 1 ***
2022-08-05T12:17:37 DEBUG read_write.c: *** stlink_read_debug32 0x00030003 at 0xe000edf0

2022-08-05T12:17:37 WARN common.c: NRST is not connected
2022-08-05T12:17:37 DEBUG common.c: Using reset through SYSRESETREQ

2022-08-05T12:17:37 DEBUG common.c: *** stlink_soft_reset ***
2022-08-05T12:17:37 DEBUG read_write.c: *** stlink_write_debug32 0xa05f0003 to 0xe000edf0
2022-08-05T12:17:37 DEBUG read_write.c: *** stlink_write_debug32 0x01000500 to 0xe000edfc
2022-08-05T12:17:37 DEBUG read_write.c: *** stlink_read_debug32 0x00030003 at 0xe000edf0
2022-08-05T12:17:37 DEBUG read_write.c: *** stlink_write_debug32 0x05fa0004 to 0xe000ed0c
2022-08-05T12:17:37 DEBUG read_write.c: *** stlink_read_debug32 0x03080001 at 0xe000edf0
2022-08-05T12:17:37 DEBUG read_write.c: *** stlink_read_debug32 0x01080001 at 0xe000edf0
2022-08-05T12:17:37 DEBUG read_write.c: *** stlink_write_debug32 0x0000001f to 0xe000ed30
2022-08-05T12:17:37 DEBUG common.c: *** stlink_exit_debug_mode ***
2022-08-05T12:17:37 DEBUG common.c: *** stlink_close ***
jdbruijn commented 2 years ago

Nice analysis! I think I have a similar issue although I didn't measure the lines. For me the target also isn't reset after writing. I'm using STLINK/V3 MINI with an STM32F405RG MCU.

CreasolTech commented 2 years ago

And if I modify the st-flash to include, at the end several NRST resets, I can't see anything: only one NRST reset in the begin and nothing else.

2022-08-05T14:00:39 DEBUG common.c: *** stlink_jtag_reset 0 ***
2022-08-05T14:00:39 DEBUG common.c: *** stlink_jtag_reset 1 ***
2022-08-05T14:00:39 DEBUG common.c: *** stlink_jtag_reset 0 ***
2022-08-05T14:00:39 DEBUG common.c: *** stlink_jtag_reset 1 ***
2022-08-05T14:00:39 DEBUG common.c: *** stlink_jtag_reset 0 ***
2022-08-05T14:00:39 DEBUG common.c: *** stlink_jtag_reset 1 ***
2022-08-05T14:00:39 DEBUG common.c: *** stlink_jtag_reset 0 ***
2022-08-05T14:00:39 DEBUG common.c: *** stlink_jtag_reset 1 ***

I can see only one NRST reset, no more resets! I expected to find 4 or 5 NRST resets: only 1!

CreasolTech commented 2 years ago

I have fixed the problem by connecting the VDD of the target MCU to a RaspberryPI GPIO: after the MCU has been programmed, I turn OFF the power supply, wait for 100ms, turn ON power supply and the firmware starts.

jdbruijn commented 2 years ago

I'd argue this should stay open as the solution is a workaround instead of a solution!

phodina commented 1 year ago

Hello, I'm facing similar issue on the STM32G05:

/gnu/store/bhxcs8lz4xj1bcsqvwx7fh412629x76p-stlink-1.7.0/bin/st-flash --debug --connect-under-reset reset
st-flash 1.7.0
Failed to parse flash type or unrecognized flash type
2022-11-16T14:18:09 DEBUG common.c: *** looking up stlink version
2022-11-16T14:18:09 DEBUG common.c: st vid         = 0x0483 (expect 0x0483)
2022-11-16T14:18:09 DEBUG common.c: stlink pid     = 0x374b
2022-11-16T14:18:09 DEBUG common.c: stlink version = 0x2
2022-11-16T14:18:09 DEBUG common.c: jtag version   = 0x16
2022-11-16T14:18:09 DEBUG common.c: swim version   = 0x5
2022-11-16T14:18:09 DEBUG common.c: stlink current mode: debug (jtag or swd)
2022-11-16T14:18:09 DEBUG usb.c: -- exit_debug_mode
2022-11-16T14:18:09 DEBUG usb.c: JTAG/SWD freq set to 0
2022-11-16T14:18:09 DEBUG common.c: *** stlink_enter_swd_mode ***
2022-11-16T14:18:09 DEBUG common.c: *** stlink_jtag_reset 0 ***
2022-11-16T14:18:09 DEBUG common.c: *** stlink_jtag_reset 1 ***
2022-11-16T14:18:09 DEBUG read_write.c: *** stlink_read_debug32 0x03030003 at 0xe000edf0
2022-11-16T14:18:09 DEBUG common.c: *** stlink_soft_reset (halt) ***
2022-11-16T14:18:09 DEBUG read_write.c: *** stlink_write_debug32 0xa05f0003 to 0xe000edf0
2022-11-16T14:18:09 DEBUG read_write.c: *** stlink_write_debug32 0x01000501 to 0xe000edfc
2022-11-16T14:18:09 DEBUG read_write.c: *** stlink_write_debug32 0x00000008 to 0xe000ed30
2022-11-16T14:18:09 DEBUG read_write.c: *** stlink_read_debug32 0x00030003 at 0xe000edf0
2022-11-16T14:18:09 DEBUG read_write.c: *** stlink_write_debug32 0x05fa0004 to 0xe000ed0c
2022-11-16T14:18:09 DEBUG read_write.c: *** stlink_read_debug32 0x02000003 at 0xe000edf0
2022-11-16T14:18:09 DEBUG read_write.c: *** stlink_read_debug32 0x02000003 at 0xe000edf0
2022-11-16T14:18:09 DEBUG read_write.c: *** stlink_read_debug32 0x02000003 at 0xe000edf0
2022-11-16T14:18:09 DEBUG read_write.c: *** stlink_read_debug32 0x02000003 at 0xe000edf0
2022-11-16T14:18:09 DEBUG read_write.c: *** stlink_read_debug32 0x02000003 at 0xe000edf0
2022-11-16T14:18:09 DEBUG read_write.c: *** stlink_read_debug32 0x02000003 at 0xe000edf0
2022-11-16T14:18:09 DEBUG read_write.c: *** stlink_read_debug32 0x02000003 at 0xe000edf0
2022-11-16T14:18:09 DEBUG read_write.c: *** stlink_read_debug32 0x02000003 at 0xe000edf0
2022-11-16T14:18:09 DEBUG read_write.c: *** stlink_read_debug32 0x02000003 at 0xe000edf0
2022-11-16T14:18:09 DEBUG read_write.c: *** stlink_read_debug32 0x02000003 at 0xe000edf0
2022-11-16T14:18:09 DEBUG read_write.c: *** stlink_read_debug32 0x02000003 at 0xe000edf0
2022-11-16T14:18:09 DEBUG read_write.c: *** stlink_read_debug32 0x03030003 at 0xe000edf0
2022-11-16T14:18:09 DEBUG read_write.c: *** stlink_read_debug32 0x00030003 at 0xe000edf0
2022-11-16T14:18:09 DEBUG read_write.c: *** stlink_read_debug32 0x00000009 at 0xe000ed30
2022-11-16T14:18:09 DEBUG read_write.c: *** stlink_write_debug32 0x0000001f to 0xe000ed30
2022-11-16T14:18:09 DEBUG common.c: stlink current mode: debug (jtag or swd)
2022-11-16T14:18:09 DEBUG common.c: Loading device parameters....
2022-11-16T14:18:09 DEBUG common.c: *** stlink_core_id ***
2022-11-16T14:18:09 DEBUG common.c: core_id = 0x0bc11477
2022-11-16T14:18:09 DEBUG read_write.c: *** stlink_read_debug32 0x410cc601 at 0xe000ed00
2022-11-16T14:18:09 DEBUG read_write.c: *** stlink_read_debug32 0x10006456 at 0x40015800
2022-11-16T14:18:09 DEBUG chipid.c: detected chip_id parameters

2022-11-16T14:18:09 DEBUG chipid.c: # Device Type: STM32G05x_G06x
2022-11-16T14:18:09 DEBUG chipid.c: # Reference Manual: RM0444
2022-11-16T14:18:09 DEBUG chipid.c: #
2022-11-16T14:18:09 DEBUG chipid.c: chip_id 0x456
2022-11-16T14:18:09 DEBUG chipid.c: flash_type 5
2022-11-16T14:18:09 DEBUG chipid.c: flash_size_reg 0x1fff75e0
2022-11-16T14:18:09 DEBUG chipid.c: flash_pagesize 0x800
2022-11-16T14:18:09 DEBUG chipid.c: sram_size 0x9000
2022-11-16T14:18:09 DEBUG chipid.c: bootrom_base 0x1fff0000
2022-11-16T14:18:09 DEBUG chipid.c: bootrom_size 0x7000
2022-11-16T14:18:09 DEBUG chipid.c: option_base 0x1fff7800
2022-11-16T14:18:09 DEBUG chipid.c: option_size 0x4
2022-11-16T14:18:09 DEBUG chipid.c: flags 0

2022-11-16T14:18:09 DEBUG read_write.c: *** stlink_read_debug32 0xffff0020 at 0x1fff75e0
2022-11-16T14:18:09 INFO common.c: STM32G05x_G06x: 36 KiB SRAM, 32 KiB flash in at least 2 KiB pages.
2022-11-16T14:18:09 DEBUG common.c: *** stlink_force_debug_mode ***
2022-11-16T14:18:09 WARN common_flash.c: Flash base use default L0 address
2022-11-16T14:18:09 DEBUG read_write.c: *** stlink_read_debug32 0000000000 at 0x40015808
2022-11-16T14:18:09 DEBUG read_write.c: *** stlink_write_debug32 0x00001800 to 0x40015808
2022-11-16T14:18:09 DEBUG common.c: *** stlink_status ***
2022-11-16T14:18:09 DEBUG usb.c: core status: 00030003
2022-11-16T14:18:09 DEBUG common.c:   core status: halted
2022-11-16T14:18:09 DEBUG common.c: *** stlink_reset ***
2022-11-16T14:18:09 DEBUG read_write.c: *** stlink_read_debug32 0x00030003 at 0xe000edf0
2022-11-16T14:18:09 DEBUG common.c: *** stlink_jtag_reset 0 ***
2022-11-16T14:18:09 DEBUG common.c: *** stlink_jtag_reset 1 ***
2022-11-16T14:18:09 DEBUG read_write.c: *** stlink_read_debug32 0x03030003 at 0xe000edf0
2022-11-16T14:18:09 DEBUG read_write.c: *** stlink_read_debug32 0x00030003 at 0xe000edf0
2022-11-16T14:18:09 DEBUG common.c: *** stlink_exit_debug_mode ***
2022-11-16T14:18:09 DEBUG common.c: *** stlink_close ***
Nightwalker-87 commented 1 year ago

This is indeed a very interesting issue with a long history of similar findings and attempts to fix reset behaviour. It would be great if someone with advanced skills could address this topic.

vgeneves commented 1 year ago

Hi,

I got a similar issue using STLink V2 with STM32F723 board. When using --connect-under-reset the mcu doesn't restart. Even when issuing st-flash reset commands after.

One workaround that seems to work for me, is to force a run (stlink_run(sl, RUN_NORMAL);) command at the end of st-flash.c just before cleanup/exit.

Ant-ON commented 1 year ago

@vgeneves Somewhere I already wrote that MCU after restarting remains in the halt state. Core must be run after reset. This is not a workaround, this is a flaw in the CLI reset command.

Nightwalker-87 commented 1 year ago

Please check commit 823187216afbaccfcfe07da4c3c5739b65820239 regarding st-flash erase and subsequent calling of st-flash write. The messages WARN common.c: NRST is not connected and Using reset through SYSRESETREQ derive from common.c lines 358/359. Thus there is no check whether a physical NRST connection is present.

Nightwalker-87 commented 1 year ago

Core must be run after reset. This is not a workaround, this is a flaw in the CLI reset command.

@Ant-ON We already have the following in flash.c L290:

    if (o.reset) {
        stlink_reset(sl, RESET_AUTO);
        stlink_run(sl, RUN_NORMAL);
    }

Is this what you meant?

Ant-ON commented 1 year ago

@Nightwalker-87 the stlink_run(sl, RUN_NORMAL); line must always be executed, not just on reset

Nightwalker-87 commented 1 year ago

So we shall place it after the if clause in flash.c:290...

Ant-ON commented 1 year ago

@Nightwalker-87 yes, you got that right

    if (o.reset) {
        stlink_reset(sl, RESET_AUTO);
    }
    stlink_run(sl, RUN_NORMAL);