You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is there a way to detect, after opening the ST-Link, when the target or the ST-Link was disconnected?
I am coding an application that requires periodic polling of the target's RAM, but also requires to detect when the target or the ST-Link was disconnected (or not yet connected) and reconnect (in hotplug) as soon as it finds the target / stlink again.
During some tests on Linux I could not get any error from stlink_read_mem32() or even stlink_status() when removing the target on the fly.. my solution was to always close and open the stlink when starting the next reading, which works without problems on Linux, but keeps giving me random "denied access" errors on Windows, something related to the libusb.
Thanks!
Gustavo
The text was updated successfully, but these errors were encountered:
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.
Hi,
Is there a way to detect, after opening the ST-Link, when the target or the ST-Link was disconnected?
I am coding an application that requires periodic polling of the target's RAM, but also requires to detect when the target or the ST-Link was disconnected (or not yet connected) and reconnect (in hotplug) as soon as it finds the target / stlink again.
During some tests on Linux I could not get any error from stlink_read_mem32() or even stlink_status() when removing the target on the fly.. my solution was to always close and open the stlink when starting the next reading, which works without problems on Linux, but keeps giving me random "denied access" errors on Windows, something related to the libusb.
Thanks!
Gustavo
The text was updated successfully, but these errors were encountered: