[reset] st-flash does not work when CPU is in sleep mode

[rogerdahl]

[reset] st-flash does not work when CPU is in sleep mode

[UweBonnes]

What version do you use? The name recently changes to st-flash. Try with recent git.

[rogerdahl]

Pulled down a new copy today and the issue has been fixed. Thank you!

[MartinNowak]

Still happens for me with a STM32F103. Any idea what is causing this bug or what commit resolved it?
I'm already using the --reset option of st-flash.

[bmarvo]

When the STM32 is in STOP2 mode, we need to assert the reset line with the ST-LINK in order to connect to it. ST-LINK Utility on windows calls this 'connect under reset'. The st-flash utility does call stlink_jtag_reset(), but I've found that this doesn't work because its either happening at the wrong time, or the second parameter is incorrect (or both). I did some testing with wireshark to see what the correct parameters are to assert and deassert the reset line and they are 0 and 1 as you would expect. st-flash is using 2 which is maybe toggle? In my fork, I implemented a fix that works by adding a connect_under_reset parameter to stlink_open_usb(...) and asserting the reset line before calling stlink_enter_swd_mode(), which matches what I saw ST-LINK Utility doing with the connect under reset option. I can work on getting a cleaner version of that into a PR.

[Nightwalker-87]

The original issue by @rogerdahl has been fixed in Release v1.0.0.

Feedback from @MartinNowak may be related to #36 and #257 and should be addressed by the changes proposed by @bmarvo. As there was no further response, I have included them with commit f767b82.

[Nightwalker-87]

There have been several approaches to implement a "connect-under-reset-feature" in the codebase.
Also various reset issues related to this topic still appear frequently.

Against this background a clean-up along with a proper implementation and testing is necessary.
The most recent approach was implemented by @geoffreymbrown.

This issue is related to: #220, #254, #261, #382, #532, #533, #692
I have opened a separate branch connect-under-reset which shall focus on this somehow essential refactoring.

Please refer to these issues for further coverage.
As this topic seems to have been fully addressed, I am finally closing this issue now.