Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

STM32G030: Reset not working properly #1260

Closed
CreasolTech opened this issue Jul 25, 2022 · 15 comments · Fixed by #1332
Closed

STM32G030: Reset not working properly #1260

CreasolTech opened this issue Jul 25, 2022 · 15 comments · Fixed by #1332
Assignees
@Ant-ON @Nightwalker-87
Labels
bug/fixed component/st-flash error/unknown-chipid os/linux programmer/STLINK/V2 Clone non-official clone devices status/resolved target/stm32g0
Milestone
v1.8.0

Comments

@CreasolTech
Copy link

CreasolTech commented Jul 25, 2022 •
edited
Loading

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
Copy link
Author

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
Copy link
Author

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
Copy link
Contributor

jdbruijn commented Aug 5, 2022

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
Copy link
Author

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
Copy link
Author

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
Copy link
Contributor

jdbruijn commented Aug 8, 2022

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

@Nightwalker-87 Nightwalker-87 reopened this Aug 8, 2022
@Nightwalker-87 Nightwalker-87 added this to the v1.7.1 milestone Aug 27, 2022
@phodina
Copy link

phodina commented Nov 16, 2022

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
Copy link
Member

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.

@Nightwalker-87 Nightwalker-87 changed the title [STM32G030]: Reset not working properly STM32G030: Reset not working properly Jan 6, 2023
@vgeneves
Copy link

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
Copy link
Collaborator

Ant-ON commented Jan 18, 2023

@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 Nightwalker-87 pinned this issue Apr 6, 2023
@Nightwalker-87
Copy link
Member

Please check commit 8231872 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
Copy link
Member

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
Copy link
Collaborator

Ant-ON commented Jun 26, 2023

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

@Nightwalker-87
Copy link
Member

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

@Ant-ON
Copy link
Collaborator

Ant-ON commented Jun 27, 2023

@Nightwalker-87 yes, you got that right

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

Nightwalker-87 added a commit that referenced this issue Jun 27, 2023
@Nightwalker-87
Fixed chip recovery after reset
2f27e8e 
(Closes #1260)
@Nightwalker-87 Nightwalker-87 unpinned this issue Jun 28, 2023
@Nightwalker-87 Nightwalker-87 mentioned this issue Sep 2, 2023
Merged
@stlink-org stlink-org locked as resolved and limited conversation to collaborators Sep 16, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@Ant-ON Ant-ON

@Nightwalker-87 Nightwalker-87

Labels
bug/fixed component/st-flash error/unknown-chipid os/linux programmer/STLINK/V2 Clone non-official clone devices status/resolved target/stm32g0
Projects
No open projects
Release v1.8.0
Status: Done
Milestone
v1.8.0
Development

Successfully merging a pull request may close this issue.

Merge branch testing into develop stlink-org/stlink
6 participants
@Ant-ON @phodina @Nightwalker-87 @CreasolTech @vgeneves @jdbruijn