Reenable USB port after it becomes unresponsive to certain devices

I routinely connect and disconnect USB devices many times when debugging and programming firmware. The devices tend to be things like USB to UART adapters, Arduino's, and ISP/JTAG/SWD programmers.

To facilitate this I use a powered hub with individual power buttons. The one I have currently is a J.Burrows 7 Port USB 3.0 Hub.

This allows me to leave several devices plugged in and swap between them with the power button. I have the hub plugged in via its USB-A cable into a port on my Mac Studio running Ventura 13.4.1, with hub power supplied by a dedicated wall wart. I also saw the same behaviour on at least one predecessor Mac desktop (an iMac), though it might have been the same hub.

Inevitably, at some stage one of the devices will fail to enumerate. It powers up, but never appears in the device tree in System Information nor in the /dev/ directory.

Then, plugging the same device into a different port on the same hub succeeds! Eventually it fails in the same way, and I move ports again, until I run out of combinations. The only fix I've found at that point is a system reboot, which resets everything to normal.

There doesn't seem to be a pattern to which device or port fails, or why. However, a sufficient trigger is to launch Arduino IDE. In particular, if I plug a device in, use it from the command line (with avrdude), and then launch Arduino IDE, the device disappears from the bus in the manner described in this question.

After the enumeration fails, if I try again I see this in the Console:

error   21:01:34.461045+1000    kernel  AppleUSBXHCICommandRing: AppleUSBXHCICommandRing::executeCommand: command[227] 0x0000000000180000 00000000 58002c01 got result 0x0000000000068e30 04000000 58008400 after 5ms (enqueued 0ms)
error   21:01:34.461061+1000    kernel  AppleUSBXHCICommandRing: AppleUSBXHCICommandRing::setAddress: completed with result code 4
error   21:01:34.461258+1000    kernel  AppleUSBXHCICommandRing: AppleUSBXHCICommandRing::executeCommand: command[228] 0x0000000000000000 00000000 58013c01 got result 0x0000000000068e40 13000000 58008400 after 0ms (enqueued 0ms)
error   21:01:34.461261+1000    kernel  AppleUSBXHCICommandRing: AppleUSBXHCICommandRing::stopEndpoint: completed with result code 19
default 21:01:34.464715+1000    kernel  AppleUSB20HubPort@08333400: AppleUSBHostPort::createDevice: failed to create device (0xe00002bc)
default 21:01:34.464724+1000    kernel  AppleUSB20HubPort@08333400: AppleUSB20HubPort::resetAndCreateDevice: failed to create device, disabling port

I'm not sure how to debug this further, but the messages lead me to suspect the behaviour is not specific to my hub. Or at least, a potential resolution is not! My theory is that the device behaves badly at some point (plausible, since I'm bringing up devices that are under development), and gets blacklisted by the system. You can imagine how confusing this is when you're debugging a suspect device!

Is there a way to undo the "disabling" of the port mentioned in the error message? Or a way to disprove my theory?

The ideas here made no difference: Reset USB bus without reboot (MacBook ignores display)

Addendum: plugging a device that has failed into another port (where it succeeds) produces this in the console, though I'm not sure how much of it is relevant. I haven't caught logs of a device failing for the first time, and not sure how I would achieve that.