[reset] Board won't start up after flashing

[JoeMerten]

Compiled most recent sources

• ecc31f7
• Host = Kubuntu 16.04 64 bit
• st-flash --version = v1.2.0-155-gecc31f7

Stm target boards:

• Stm32F401C-Disco (chip-id = 0x0423, st-info --descr = F4 device (low power))
• Stm32F411E-Disco (chip-id = 0x0431, st-info --descr = F4 device (low power) - stm32f411re)
• both Stlink/v2-onboard

Stlink commandline:

build/Release/st-flash --reset write "myprog.bin" 0x8000000

Output:

2016-12-25T20:47:55 INFO src/common.c: Loading device parameters....
2016-12-25T20:47:55 INFO src/common.c: Device connected is: F4 device (low power), id 0x6423
2016-12-25T20:47:55 INFO src/common.c: SRAM size: 0x10000 bytes (64 KiB), Flash: 0x40000 bytes (256 KiB) in pages of 16384 bytes
2016-12-25T20:47:55 INFO src/common.c: Attempting to write 209516 (0x3326c) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08020000 erasedEraseFlash - Sector:0x5 Size:0x20000 
2016-12-25T20:47:58 INFO src/common.c: Finished erasing 6 pages of 131072 (0x20000) bytes
2016-12-25T20:47:58 INFO src/common.c: Starting Flash write for F2/F4/L4
2016-12-25T20:47:58 INFO src/flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 12908
2016-12-25T20:48:03 INFO src/common.c: Starting verification of write complete
2016-12-25T20:48:08 INFO src/common.c: Flash written and verified! jolly good!

Expected/description:

After finished writing to flash, the flashed binary don't start up (regardless if I call st-flash with or without --reset parameter). I need to press the "RESET" button of the discovery board to start my application.

What's the way to automatically start the flashed binary?

[xor-gate]

Thats actually a very good question. Probably we need a option like run-after-flash. I'm not 100% sure why it doesn't reset after flash currently.

[JoeMerten]

Looking into src/tools/flash.c, I saw some code which is executed when I pass the --reset option:

if (o.reset) {
    stlink_jtag_reset(sl,2);
    stlink_reset(sl);
}

but this seems not to reset the microcontroller.
Note: I'd added printf() into the code to make sure that the reset code was really reached.

[JoeMerten]

Trying the reset command also doesn't start my flashed application:

$ build/Release/st-flash reset
st-flash 1.2.0-155-gecc31f7
2016-12-26T00:54:15 INFO src/common.c: Loading device parameters....
2016-12-26T00:54:15 INFO src/common.c: Device connected is: F4 device (low power), id 0x6423
2016-12-26T00:54:15 INFO src/common.c: SRAM size: 0x10000 bytes (64 KiB), Flash: 0x40000 bytes (256 KiB) in pages of 16384 bytes

[JoeMerten]

Added stlink_run(sl); after stlink_reset(sl); won't help.

[xor-gate]

I have just merged a possible fix from PR #534. Could you test latest master?

[JoeMerten]

Testet with most recent 01b9e16 but same behaviour.

[aoreh]

Hi! Any progress on this issue?
Have the same behavior with stm32f417vg based board :(, with attached or detached SWRST pin. But it looks that device starts for a few milliseconds and then holds. It looks that this "starting and holding" happens during call to "stlink_exit_debug_mode"
After manual resetting device works fine.
At the same time if connect device to Win system and program it with STM ST-Link utility - it starts working w/o any problem.

[xor-gate]

SWRST pin is independed of CPU core state (running,halted). Which register-controlled. There is no progress on this issue and I'm happy to receive a correct fix for this.

[aoreh]

Ok, but why it doesn't work without SWRST pin? Program runs for a few milliseconds (I see log messages from board via UART) and then holds :( As I said - no problem when using STM's original SW on Win.

About SWRST: unfortunately work with device remotely, so can't check what happens with oscilloscope :(, may be something wrong with this pin it self.

PS. Is it important st-link FW version?
I have: ST-LINK Firmware version : V2J25S4
And using SW: st-info --version = v1.3.1-4-g9d08810

[aoreh]

Tried with OpenOCD, didn't re-flash the device, just "reset run" - and device started working.

[Ant-ON]

@Nightwalker-87 This issue most like fixed by #1071 (software reset rework)

[Nightwalker-87]

Closed by #1071.