st-util should detect when USB commands fail

[galexander1]

I run st-util as a long-running daemon to interface with a sensor monitoring project. About once a month, the USB spontaneously resets, and then strace on st-util shows it is repeatedly failing:

ioctl(9, USBDEVFS_SUBMITURB, 0x8e35bd0) = -1 ENODEV (No such device)

And, for example, 'm' (gdb remote read memory) commands silently fail and simply return stale data that happens to sit in a buffer.

I haven't investigated in detail yet but my assumption is that libusb is returning an error code that gets lost at some point.

For my purposes, it would be most convenient if st-util were simply to re-connect to the USB, but I imagine other people would find that behavior kind of objectionable (state would change without gdb necessarily being informed). So I figure the proper answer is for st-util to simply terminate when the USB device goes away. (comments?)

So I will be submitting a patch "soon" to achieve that effect.

[galexander1]

I need some advice.

In the interests of not inventing a comprehensive error-handling system which would probably step on everyone's toes, I've simply changed 'm' (memory read) and 'M' (memory write) to no longer silently fail. read returns 0 bytes if it fails (instead of a stale buffer), and write returns "E00" instead of "OK". I'll submit that pull request in a few hours.

But in the interests of not getting into the business of process management in my "gdb client" program, wouldn't it be awesome if there was a way to re-connect to the device without re-starting st-util?

It looks like st-util does not currently implement the 'k' (Kill request) gdb remote command. From the documentation at

https://sourceware.org/gdb/onlinedocs/gdb/Packets.html#index-g_t_0040samp_007bk_007d-packet-3287

It says "For a bare-metal target, it may power cycle or reset the target system." So it seems to me, this would be an acceptable command to use for this purpose. It would close down the existing stlink_t connection and establish a new one.

It seems harmless to me, since there wasn't already a 'k' function. I don't know under what circumstances gdb itself would send 'k'. Presumably if the user typed "kill" at the gdb prompt? I wonder if this would help with issue #449?

What do you all think? Thanks!

[xor-gate]

I agree with both (but they could be two separate issues). Silent fail is bad bahaviour it should fail "good" and with an error. Extending the gdb-server is no problem as this improves the st-util.
Propose on or more pull-requests and we can cary on from there.

Thank you for you feedback!

[galexander1]

Pull request #527 just guarantees the read memory (m) and write memory (M) commands will not pretend to succeed if there is an stlink error.

Pull request #528 adds the Kill request (k) command, which closes the stlink_t and then opens a new one.

Hope I did all this right :)

Thanks all! I really enjoy my STM32 and stlink is the central tool.

[xor-gate]

Thank you for your effort. This will be put in the v1.3.0 release very soon 👍 .