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

[rogerdahl]

In general, the st-flash utility has been working fairly well for me. Thank you for your excellent work, guys. I believe the issues I've had, except for the one I am creating this ticket for, have open tickets already.

The problem I'm having is that I'm planing on creating an interrupt driven design. So I have written an experimental program that sets up an interrupt (connected to the user button) and then puts the CPU to sleep by running the __WFI() function. When I flash a program that runs that function, subsequent flashing with st-flash does not work. To get back in touch with the chip, I have to boot into Windows and use the STM-32 ST-LINK Utility from ST to erase the flash. A clue to what is wrong is that the STM-32 ST-LINK Utility does not work either, unless "Connect under Reset" is enabled in Settings.

After flashing the program that runs the __WFI() function, any attempt to flash causes the following error:

dahl@ubuntu:~/Desktop/3/stlink/example/32l_lcd$ make write
../../flash/flash write lcd.bin 0x08000000
2012-02-09T23:25:54 INFO src/stlink-common.c: Loading device parameters....
2012-02-09T23:25:54 WARN src/stlink-common.c: unknown chip id! 0
stlink_sram_flash() == -1
make: *** [write] Error 255

Any attempt to erase causes (note how the program displays a different chip id):

make: *** [write] Error 255
dahl@ubuntu:~/Desktop/3/stlink/example/32l_lcd$ ../../flash/flash erase
2012-02-09T23:28:01 INFO src/stlink-common.c: Loading device parameters....
2012-02-09T23:28:01 WARN src/stlink-common.c: unknown chip id! 0xe0042000
Mass erasing

If I hold the Reset button while flashing:

ahl@ubuntu:~/Desktop/3/stlink/example/32l_lcd$ ../../flash/flash erase
2012-02-09T23:28:28 INFO src/stlink-common.c: Loading device parameters....
2012-02-09T23:28:28 INFO src/stlink-common.c: Device connected is: L1 Med-density device, id 0x10386416
2012-02-09T23:28:28 INFO src/stlink-common.c: SRAM size: 0x4000 bytes (16 KiB), Flash: 0 bytes (0 KiB) in pages of 256 bytes

Even after I erase the flash in Windows, I get the following. This is fixed by pushing the Reset button on the card:

dahl@ubuntu:~/Desktop/3/stlink/example/32l_lcd$ make write
../../flash/flash write lcd.bin 0x08000000
2012-02-10T14:13:21 INFO src/stlink-common.c: Loading device parameters....
2012-02-10T14:13:21 INFO src/stlink-common.c: Device connected is: L1 Med-density device, id 0x10386416
2012-02-10T14:13:21 INFO src/stlink-common.c: SRAM size: 0x4000 bytes (16 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 256 bytes
2012-02-10T14:13:21 INFO src/stlink-common.c: Attempting to write 7332 (0x1ca4) bytes to stm32 address: 134217728 (0x8000000)
2012-02-10T14:13:21 WARN src/stlink-common.c: pecr.pelock not clear (0x7)
2012-02-10T14:13:21 WARN src/stlink-common.c: Failed to erase_flash_page(0x8000000) == -1
stlink_fwrite_flash() == -1
make: *** [write] Error 255

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