second session on OSX fails without a power cycle

[peabody124]

Connecting to an F4 discovery board with st-util works perfectly the first time. However, after exiting with ctrl-c and running again I get errors from libusb. Here is a verbose log from the two executions:

$ ./gdbserver/st-util -v99
2011-11-23T11:41:02 DEBUG src/stlink-common.c: stlink current mode: dfu
2011-11-23T11:41:02 INFO src/stlink-usb.c: -- exit_dfu_mode
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_exit_dfu_mode ***
2011-11-23T11:41:02 DEBUG src/stlink-common.c: stlink current mode: mass
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_enter_swd_mode ***
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** looking up stlink version
2011-11-23T11:41:02 DEBUG src/stlink-common.c: st vid         = 0x0483 (expect 0x0483)
2011-11-23T11:41:02 DEBUG src/stlink-common.c: stlink pid     = 0x3748
2011-11-23T11:41:02 DEBUG src/stlink-common.c: stlink version = 0x2
2011-11-23T11:41:02 DEBUG src/stlink-common.c: jtag version   = 0xe
2011-11-23T11:41:02 DEBUG src/stlink-common.c: swim version   = 0x0
2011-11-23T11:41:02 DEBUG src/stlink-common.c:     notice: the firmware doesn't support a swim interface
2011-11-23T11:41:02 INFO src/stlink-common.c: Loading device parameters....
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_core_id ***
2011-11-23T11:41:02 DEBUG src/stlink-common.c: core_id = 0x00000000
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
2011-11-23T11:41:02 WARN src/stlink-common.c: unknown chip id! 0
Chip ID is 00000000, Core ID is  00000000.
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_force_debug_mode ***
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_reset ***
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe0002000
KARL - should read back as 0x03, not 60 02 00 00
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe0002008
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe000200c
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe0002010
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe0002014
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe0002018
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe000201c
init watchpoints
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe000edfc
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe0001028
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe0001038
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe0001048
2011-11-23T11:41:02 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe0001058
Listening at *:4242...
^C
$ ./gdbserver/st-util -v99
libusb_handle_events() timeout
[!] send_recv
2011-11-23T11:41:14 DEBUG src/stlink-common.c: stlink mode: unknown!
libusb_handle_events() timeout
[!] send_recv
2011-11-23T11:41:17 DEBUG src/stlink-common.c: stlink mode: unknown!
2011-11-23T11:41:17 DEBUG src/stlink-common.c: *** stlink_enter_swd_mode ***
2011-11-23T11:41:17 DEBUG src/stlink-common.c: *** looking up stlink version
libusb_submit_transfer(-9)
[!] send_recv
2011-11-23T11:41:17 DEBUG src/stlink-common.c: st vid         = 0x0000 (expect 0x0483)
2011-11-23T11:41:17 DEBUG src/stlink-common.c: stlink pid     = 0x0000
2011-11-23T11:41:17 DEBUG src/stlink-common.c: stlink version = 0x2
2011-11-23T11:41:17 DEBUG src/stlink-common.c: jtag version   = 0xe
2011-11-23T11:41:17 DEBUG src/stlink-common.c: swim version   = 0x0
2011-11-23T11:41:17 DEBUG src/stlink-common.c:     notice: the firmware doesn't support a swim interface
2011-11-23T11:41:17 INFO src/stlink-common.c: Loading device parameters....
2011-11-23T11:41:17 DEBUG src/stlink-common.c: *** stlink_core_id ***
libusb_submit_transfer(-9)
[!] send_recv
2011-11-23T11:41:17 DEBUG src/stlink-common.c: core_id = 0x00000000
2011-11-23T11:41:17 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
libusb_handle_events() timeout
[!] send_recv
2011-11-23T11:41:20 WARN src/stlink-common.c: unknown chip id! 0x8023
Chip ID is 00008023, Core ID is  00000000.
2011-11-23T11:41:20 DEBUG src/stlink-common.c: *** stlink_force_debug_mode ***
libusb_handle_events() timeout
[!] send_recv
2011-11-23T11:41:23 DEBUG src/stlink-common.c: *** stlink_reset ***
libusb_handle_events() timeout
[!] send_recv
2011-11-23T11:41:26 DEBUG src/stlink-common.c: *** stlink_write_mem32 4 bytes to 0xe0002000

[peabody124]

Ok - and per suggestion from karlp I realized that if you exit from gdb then it runs through _stlink_usb_close but not if you just ctrl-c. In the former case I can run st-util without power cycling.

[xor-gate]

As this issue is approximate 5 years I'm closing this in favor of the new v1.2.0 release of stlink library and tools. Feel free to open a new issue when the problem still remains.

[Nightwalker-87]

Ok - and per suggestion from karlp I realized that if you exit from gdb then it runs through _stlink_usb_close but not if you just ctrl-c. In the former case I can run st-util without power cycling.

We should check whether ctrl-c can run _stlink_usb_close as well or if this has been addressed in the meanwhile.

[chenguokai]

We should check whether ctrl-c can run _stlink_usb_close as well

It’s possible with a signal handler. Hooking SIGINT will do the job. As long as the handler will finally exit, it will be portable at least for UNIX(-like) systems.

[Nightwalker-87]

Hmm, I found this 5be889e and this c37975c in our git commit-history. Anything helpful?
Could this be an old regression from the second commit?

[chenguokai]

Could this be an old regression from the second commit?

Likely to be. What the first commit did is exactly what I suggested.

[Nightwalker-87]

Thanks for your feedback. 👍
This issue is now finally resolved and can be allocated correctly.