I had a need to test the insert/remove a whole bunch for a while. Because the timing worked out, I ended up getting a programmable USB hub [1]. It worked well for my needs, but I'm not sure I'd trust it enough for a really inaccessible location.

I do wish I could find a not stupid priced version of this concept that does USB 3.1

[1] https://capablerobot.com/products/programmable-usb-hub/

Took me a while to find this again, but here you go: https://www.yepkit.com/product/300110/YKUSH3, a 3-port USB 3.1 Hub with switchable Vbus that doesn't cost an arm and a leg.

we use these in our CI/CD pipelines as we deal with embedded hardware. they work absolutely awesome for power cycling stuck USB peripherals or powering USB-powered boards for tests.

I’me working on an embedded project and would like to setup a CI/CD pipeline. Do you have any recommended resources?

There was a presentation about CI/CD for embedded systems at HITB+CyberWeek a couple of days ago: https://cyberweek.ae/2020/ci-cd-with-sast-and-dast-for-embed...

A recording can be found here: https://www.youtube.com/watch?v=nFytbVFMLfA

Thanks!

Very nice find! Thanks a ton!

Pegasus Astro make a switchable six-port USB3.1 hub which is suitable for very wide temperature range. Costs about 200 Euro:

https://pegasusastro.com/products/usb-control-hub/

Checkout this Hub Control library for C. https://github.com/codazoda/hub-ctrl.c

I'm the maintainer, but I can only take credit for updating a single line, uploading to GitHub, and doing PR's (mostly to the README) every once in a while.

This brings back memories from about a year ago when i was doing robotics.

Azure Kinect DK depth cameras had a firmware/hardware issue that would let it get stuck every now and then, and it would have to be power cycled. You'd imagine it'd be easy, but it was surprisingly hard. Ended up getting a new usb hub that supports power cycle...

If the system is well designed, this power cycle should be a rare event (ie. maybe once per year).

For that rare event, it doesn't seem worth writing code to power cycle a single USB peripheral (and then write and test all the code to clear the error states at each level of the stack and bring that peripheral back up again).

Instead, power cycle the entire system. Have a small hardware watchdog which, when not being tickled, will power off the whole system for 5 seconds and power everything back on.

Write code to periodically tickle the hardware watchdog when everything is 100% healthy, or when 3 reboots have happened in short succession (you'd prefer the system up with 90% of the hardware working than bootlooping).

Have a mosfet between the 5 volt regulator and the device. At 20 milliohm, drawing .1 amp, that's only 2 millivolt drop. Or, since it's a low volume design, just throw a relay in there.

The article links to a thread on the linux-usb mailing list where the author mentions he does sometimes resort to that.

It sounds to me like the author genuinely wants to have a discussion about some of the quirks in the USB protocol. I don't see anything wrong with pursuing all available options.

I have a buggy flashing tool that often ends up needing a hard power cycle, and I wish this were easier just to prevent wear on the physical port...