Without this change going to lightsleep stops the USB peripheral clock, and can lead to either the device going into a weird state or the host deciding to issue a bus reset.

This change only keeps the USB peripheral clocks enabled if the USB device is currently active and a host has configured the device. Otherwise USB clocks are disabled same as before.

Increases power consumption in light sleep (measured at the USB port for a PICO board as 1.2-1.3mA without this change, and 3.4-3.5mA with this change). I think can argue that if you have a working active USB host connection, an extra 2mA is unlikely to be significant.

(EDIT: Above measurement was originally off by a factor of 10, corrected in comments.)

As discussed athttps://github.com/orgs/micropython/discussions/14401

Tested with

• The code supplied in the linked discussion, viampremote run
• mpremote a1 exec "import machine; machine.lightsleep(5000)" (plus some longer and shorter delays, up to 30 seconds).
• Same command as above, via REPL (allows interactively sending bytes to the USB device to try and bring it back.)

Details

Logic analyser shows that without this change the USB Host continues sending SoF and other requests to the sleeping device, and it doesn't respond so every transfer is an error. On my system, the host seems to keep trying indefinitely. After waking, TinyUSB ends up in a bad state and doesn't set up any new transfers itself (i.e. the USB-CDC doesn't send any data to the host.) If using a REPL, pressing a key to send some data from the host to the device is enough to make it come back from this weird state and it seems to resume normal operations.

Behaviour seems to vary between host controllers - the discussion includes anexample of the host deciding the device is no longer responding and resetting it. I wasn't able to reproduce this here, can only guess it depends on the host controller (and/or maybe the hub controller, especially for superspeed hubs.)

With this change applied, the USB device continues to respond to host transfers and (presumably) will even complete pending endpoint transfers. All other requests are NAKed while still asleep, but the interaction with the host seems to resume correctly on wake.

Alternatives

One alternative approach would be to disconnect the USB device pins when going into lightsleep. This would cause the host to definitely see the device as disconnected, rather than ending up in the current weird in-between states. Also no increase in power usage. If we do the planned work to support transparent USB serial disconnect/reconnect in mpremote then it will probably be possible for mpremote to cleanly recover the connection on wake, also.

I also did some experiments with getting TinyUSB and the host to recover from the weird in-between state, without the host needing to initiate an OUT transfer. This obviously doesn't help for hosts which trigger a full bus reset, but might help for some hosts. I had a little unreliable success with this, but it seems flaky.

This work was funded through GitHub sponsors.