MCU hotplug - stlink doesn't recover the STLINKV2 from error state.

[rewolff]

trafficstars

When hotplugging CPUs or boards, the STLINK often goes into "error" state. Not sure if it CAN be recovered, but if possible, resetting the error state would be nice. :-)

[rewolff]

I currently know of only one way to clear the error state: unplug and replug the STLINK.

The cause for the "errorstate" is, I suspect, that the decoupling caps in the target pull the 3.3V on the stlink low enough that the STLINk crashes. So maybe there is nothing to recover.

[rewolff]

Old version: (aborts as expected).

assurancetourix:~> st-util -m
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
2020-03-21T17:17:03 INFO src/stlink-common.c: Loading device parameters....
libusb_handle_events() | has_error
[!] send_recv
libusb_handle_events() | has_error
[!] send_recv
libusb_handle_events() | has_error
[!] send_recv
2020-03-21T17:17:03 WARN src/stlink-common.c: unknown chip id! 0
assurancetourix:~> 

Recent version that does not abort.

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:12:32 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:12:32 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:12:32 INFO gdb-server.c: Listening at *:4242...

[Nightwalker-87]

Not very nice indeed... Thx for putting this up. :+1:

[Nightwalker-87]

Related to #449 and #244.

[chenguokai]

I guess, this problem may be restored to the expected aborts behaviour by applying the same method used in https://github.com/stlink-org/stlink/pull/913 What might be challenging is to reproduce this error with host debugger on st-util and find out what kinds of error need to be treated as critical.

[Nightwalker-87]

@rewolff: Are you working on this?

[rewolff]

Sorry.... Paid work takes precedence....

Should I find some free time... Does github make it easy for me to vew the issues you've tagged me on?

[Nightwalker-87]

Thats ok. I just wanted to know if there was any further activity planned here. To me assigning topics just helps to stay on track who is involved with which topic. So I may ask every once in a while to stay up to date and to maintain an overview.

Yes, you can add the author:rewolff tag when searching open issues or select yourself in the "Author" dropdown menu in the issue header bar (which leads to the same result).

[Nightwalker-87]

@Ant-ON This may also be addressed in your recent PR.

[Ant-ON]

@Nightwalker-87 Not, it's not related. To solve this issue, needs to catch LIBUSB_ERROR_IO errors and calls libusb_reset_device

[Nightwalker-87]

@rewolff or anyone else who may have run into this: Please give us an update on this with after testing with v1.6.0, v1.6.1 and v1.7.0.

[Nightwalker-87]

This issue is now closed due to inactivity. Please also note that any version prior to v1.7.0 is unsupported according to our #Security Policy. Should the problem persist, please retry with the latest version in the develop branch. If this is the case, one should then open a new ticket.