Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

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

Open
shimniok opened this Issue · 4 comments

4 participants

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.