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.

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

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

Closed
rogerdahl opened this issue Feb 10, 2012 · 6 comments
Closed

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

rogerdahl opened this issue Feb 10, 2012 · 6 comments

Comments

@rogerdahl
Copy link

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

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

@rogerdahl
Copy link
Author

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

@MartinNowak
Copy link
Contributor

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

bmarvo commented Feb 25, 2020

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.

@bmarvo bmarvo self-assigned this Feb 25, 2020
@Nightwalker-87 Nightwalker-87 modified the milestones: v1.6.0, v1.6.1 Feb 25, 2020
@Nightwalker-87 Nightwalker-87 changed the title flash does not work when CPU is in sleep mode flashing: flash does not work when CPU is in sleep mode Mar 17, 2020
@Nightwalker-87
Copy link
Member

Nightwalker-87 commented Mar 31, 2020

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 Nightwalker-87 self-assigned this Jun 17, 2020
@Nightwalker-87 Nightwalker-87 modified the milestones: a) Old issues, v1.6.2 Jun 17, 2020
@Nightwalker-87 Nightwalker-87 changed the title flashing: flash does not work when CPU is in sleep mode reset: st-flash does not work when CPU is in sleep mode Jun 17, 2020
@Nightwalker-87
Copy link
Member

Nightwalker-87 commented Jun 17, 2020

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.

@Nightwalker-87 Nightwalker-87 removed their assignment Jun 17, 2020
@Nightwalker-87 Nightwalker-87 changed the title reset: st-flash does not work when CPU is in sleep mode [reset] st-flash does not work when CPU is in sleep mode Oct 22, 2020
@stlink-org stlink-org locked as resolved and limited conversation to collaborators Mar 10, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.