stlink-org / stlink

Open source STM32 MCU programming toolset
BSD 3-Clause "New" or "Revised" License
4.45k stars 1.24k forks source link

st-util cannot load my chip parameters, either can *.elf file be loaded, why and how to solve it ? #194

Closed gitsocket closed 3 years ago

gitsocket commented 10 years ago

I use stm32f103vet6 with 512K flash and 64K ram. When I start st-util, it showed that:

STM32F1-workarea/Project/GPIO-example$ sudo st-util
libusb_handle_events() timeout [!] send_recv libusb_submit_transfer(-6) [!] send_recv 2013-12-07T02:10:23 INFO src/stlink-common.c: Loading device parameters.... libusb_handle_events() timeout [!] send_recv libusb_submit_transfer(-6) [!] send_recv libusb_submit_transfer(-6) [!] send_recv 2013-12-07T02:10:26 WARN src/stlink-common.c: unknown chip id! 0 libusb_submit_transfer(-6) [!] send_recv libusb_submit_transfer(-6) [!] send_recv Chip ID is 00000000, Core ID is 00000000. libusb_submit_transfer(-6) [!] send_recv Listening at *:4242...

And in arm-none-eabi-gdb 's view :

(gdb) target remote localhost:4242 Remote debugging using localhost:4242 0x00007f78 in ?? () (gdb) load main.elf Loading section .isr_vector, size 0x1d0 lma 0x8000000 Load failed

I'm sure I have set the board set from SRAM so that it can be reprogramed, and I alse tried keeping reset the board. I have no idea about that... Why and how to solve the problem?

cstratton commented 10 years ago

That kind of error output on st-util startup typically means it can't talk to the STLINK SWD adapter.

Sometimes it's as simply as replugging the USB, and killing any other copies of st-util (or st-flash) that might be running.

Is that board old enough that it's an STLINKV1 and not STLINKV2 SWD adapter? What host operating system are you on? If linux and an STLINKV1 you need the usb_storage quirks fix to prevent it from trying to mount as a broken mass storage drive.

Nightwalker-87 commented 3 years ago

The described behaviour is related to the external libusb library preventing communication to the device. This issue should be fixed since #374.