Runtime errors with st-flash, unable to consistently flash STM32F4 Discovery

[shimniok]

This probably relates to other issues I've read here. First... I'm on Linux Mint 14, I've tried running libusbx and libusb, and get the same issues with st-flash. I'm using the command st-flash write my.bin 0x8000000. When it works the Discovery behaves as expected, blinking LEDs in sequence. Sometimes the errors appear, it apparently successfully flashes (but requires disconnecting/reconnecting to reset the STM32 onboard).

The errors include:
libusb_handle_events() | has_error
FATAL src/stlink-common.c: flash loader run error
[!] _stlink_usb_core_id() send_recv

I've not yet detected what the patterns are. It doesn't "come back" every time after disconnect/reconnect. Sometimes it works a couple times in a row, sometimes once. Sometimes it gives errors and sort of finishes, other times it gives the fatal error, sometimes segmentation faults, sometimes not.

I did a bit of hacking on the code to get a better idea of what errors are happening, while simultaneously starting to learn a few little things about libusb. Anyway here are a couple of sample runs that failed after running successfully three times in a row.

$ st-flash write stm32f4_template.bin 0x8000000
2013-02-08T13:32:25 INFO src/stlink-usb.c: -- exit_dfu_mode
2013-02-08T13:32:25 INFO src/stlink-common.c: Loading device parameters....
2013-02-08T13:32:25 INFO src/stlink-common.c: Device connected is: F4 device, id 0x20006411
2013-02-08T13:32:25 INFO src/stlink-common.c: SRAM size: 0x30000 bytes (192 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 16384 bytes
2013-02-08T13:32:25 INFO src/stlink-common.c: Attempting to write 10176 (0x27c0) bytes to stm32 address: 134217728 (0x8000000)
EraseFlash - Sector:0x0 Size:0x4000
Flash page at addr: 0x08000000 erased
2013-02-08T13:32:25 INFO src/stlink-common.c: Finished erasing 1 pages of 16384 (0x4000) bytes
2013-02-08T13:32:25 INFO src/stlink-common.c: Starting Flash write for F2/F4
2013-02-08T13:32:25 INFO src/stlink-common.c: Successfully loaded flash loader in sram
size: 10176
libusb_handle_events() | has_error
[!] send_recv
libusb_handle_events() | has_error
[!] send_recv
libusb_handle_events() | has_error
[!] send_recv
libusb_handle_events() timeout
[!] send_recv
libusb_submit_transfer(-6)
[!] send_recv
libusb_submit_transfer(-6)
[!] send_recv
... [hundreds of these] ...
2013-02-08T13:32:29 FATAL src/stlink-common.c: flash loader run error

$ st-flash write stm32f4_template.bin 0x8000000
2013-02-08T13:33:26 INFO src/stlink-usb.c: -- exit_dfu_mode
2013-02-08T13:33:26 INFO src/stlink-common.c: Loading device parameters....
2013-02-08T13:33:26 INFO src/stlink-common.c: Device connected is: F4 device, id 0x20006411
2013-02-08T13:33:26 INFO src/stlink-common.c: SRAM size: 0x30000 bytes (192 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 16384 bytes
2013-02-08T13:33:26 INFO src/stlink-common.c: Attempting to write 10176 (0x27c0) bytes to stm32 address: 134217728 (0x8000000)
EraseFlash - Sector:0x0 Size:0x4000
Flash page at addr: 0x08000000 erased
2013-02-08T13:33:26 INFO src/stlink-common.c: Finished erasing 1 pages of 16384 (0x4000) bytes
2013-02-08T13:33:26 INFO src/stlink-common.c: Starting Flash write for F2/F4
2013-02-08T13:33:26 INFO src/stlink-common.c: Successfully loaded flash loader in sram
size: 10176
libusb_handle_events() | has_error
[!] send_recv
libusb_handle_events() | has_error
[!] send_recv
libusb_handle_events() | has_error
[!] send_recv
libusb_handle_events() | has_error
[!] send_recv
libusb_handle_events() | has_error
[!] send_recv
libusb_handle_events() | has_error
[!] send_recv
libusb_handle_events() | has_error
[!] send_recv
libusb_handle_events() | has_error
[!] send_recv
libusb_handle_events() | has_error
[!] send_recv
2013-02-08T13:33:27 INFO src/stlink-common.c: Starting verification of write complete
2013-02-08T13:33:27 INFO src/stlink-common.c: Flash written and verified! jolly good!

$ st-flash write stm32f4_template.bin 0x8000000
2013-02-08T15:21:37 INFO src/stlink-common.c: Loading device parameters....
2013-02-08T15:21:37 INFO src/stlink-common.c: Device connected is: F4 device, id 0x20006411
2013-02-08T15:21:37 INFO src/stlink-common.c: SRAM size: 0x30000 bytes (192 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 16384 bytes
2013-02-08T15:21:38 INFO src/stlink-common.c: Attempting to write 10176 (0x27c0) bytes to stm32 address: 134217728 (0x8000000)
EraseFlash - Sector:0x0 Size:0x4000
Flash page at addr: 0x08000000 erased
2013-02-08T15:21:38 INFO src/stlink-common.c: Finished erasing 1 pages of 16384 (0x4000) bytes
2013-02-08T15:21:38 INFO src/stlink-common.c: Starting Flash write for F2/F4
2013-02-08T15:21:38 INFO src/stlink-common.c: Successfully loaded flash loader in sram
size: 10176
libusb_handle_events() | has_error
[!] send_recv
libusb_handle_events() | has_error
[!] send_recv
libusb_handle_events() | has_error
[!] send_recv
libusb_handle_events() | has_error
[!] send_recv
libusb_handle_events() | has_error
[!] send_recv
libusb_handle_events() | has_error
[!] send_recv
libusb_handle_events() | has_error
[!] send_recv
libusb_handle_events() timeout
[!] send_recv
libusb_submit_transfer(-6)
[!] send_recv
Segmentation fault

Any ideas what might be the issues here? I read on one of the other issues something about not properly closing upon CTRL-C and that appears to be the case with the fatal error, it just exits without any attempt to free handles, cancel transfers, etc. I still can't figure out where it's generating the seg fault except that gdb suggested it was within libusb do_close() so I guess something bad and evil is getting passed in...

I'd love to at least try to tweak the code toward more stability, but hoping for a few pointers in the right direction.

Thanks,
Michael

[Nomados]

I have the same problem flashing F4Discovery under ubuntu 12.04 and 12.10.
Moreover. evren if file flashed succesfully it can be corrupted in uC memory (if it is rather big)!!! I killed a couple of days before understand why my old projects refused to work! Flashing under windows solved the problem (same hex)!

[max038]

I met the same problem when flashing some bigger files (400k~500k), another problem is that after upgrading to a newer st-link firmware (17s), it even couldn't work!

[rewolff]

This might be related to what I'm seeing.....
The flash operation and/or the start of the program is not reliable unless I have reset the chip using the reset button. So I have the "workaround" that I hit "reset", then load my new program, and then hit "c" for continue.

Oh.. I'm using st-util and gdb .

I have the impression that although the flash operation seems successful, the old program remains in the flash.

[Nomados]

I used the last version and problem seems to be solved

[Nightwalker-87]

Fixed in #151.