STLink in error state does not abort the program.

[rewolff]

After changing a few things I suddenly decided to try to test "no device attached". I detached the target ground pin and I think this sent the STLINK into an error state.

When the STLINK is in error state, starting up as normal is not the right thing to do.

assurancetourix:~> ~/stm32/stlink.git2/build/Release/src/gdbserver/st-util -m
st-util 1.6.0-33-gb8813fa-dirty
[!] send_recv send request failed: LIBUSB_ERROR_IO
[!] send_recv STLINK_GET_VERSION
[!] send_recv send request failed: LIBUSB_ERROR_IO
[!] send_recv STLINK_GET_CURRENT_MODE
[!] send_recv send request failed: LIBUSB_ERROR_IO
[!] send_recv STLINK_GET_CURRENT_MODE
[!] send_recv send request failed: LIBUSB_ERROR_IO
[!] send_recv STLINK_DEBUG_ENTER
[!] send_recv send request failed: LIBUSB_ERROR_IO
[!] send_recv STLINK_JTAG_DRIVE_NRST
[!] send_recv send request failed: LIBUSB_ERROR_IO
[!] send_recv STLINK_DEBUG_RESETSYS
[!] send_recv send request failed: LIBUSB_ERROR_IO
[!] send_recv STLINK_DEBUG_READCOREID
2020-03-21T17:10:40 ERROR common.c: Failed to read core_id
[!] send_recv send request failed: LIBUSB_ERROR_IO
[!] send_recv STLINK_JTAG_READDEBUG_32BIT
2020-03-21T17:10:40 WARN common.c: Invalid flash type, please check device declaration
[!] send_recv send request failed: LIBUSB_ERROR_IO
[!] send_recv STLINK_DEBUG_RESETSYS
2020-03-21T17:10:40 INFO gdb-server.c: Listening at *:4242...

[rewolff]

Closed by #890.

[rewolff]

Hey Nightwalker, I might seem to be able to fix a thing or two, but this one is out of my league. I can program Unix-programs just fine, and I can write embedded stuff for AVR and STM, but interacting with an STLINK is not my specialty.

The previous things I fixed were simple "just search for where the message comes from" and change that. But this one would be nice-to-fix if someone who knows the STLINK hardware and could take a look.

Between the errors of an older version and the latest git... it looks as if any libusb interaction with the STLINK is met with an error: The kernel knows the device is there, but the device is no longer responding through USB. That would make it impossible to fix. That's what I think is the case, but it would be a good idea not to trust me and confirm with someone who knows more than me. (about this).