I think this is to be expected.

That's a, hmmm, how shall I put it, a surprising statement. ;-)

One would assume that once the CDC times out, Micropython would simply try to reestablish a reliable comm channel. A hard device reset isn't necessarily what comes to mind first. And the fact that it sometimes crashed on disconnect, other times on reconnect does not instill confidence.

So for a system that needs to be connected and disconnected while running, it would be best to rip out the entire USB subsystem from firmware and reprogram that CDC functionality in a loadable module. That way one could catch error conditions and handle them in a graceful manner.

Thanks @Josverl

Actually I tried it with original PICO, PICO2 boards as well as cheap china clones.
All were external powered (5.04V…5.05V (including 1000µF Elko || 1µF ceramic cap.))
They all crash, as soon as either a disconnect or a reconnect occurs.
And they even crash when there's no USB CDC communication going on at all.
Of course, the USB stack remains active in the background and responds to the incoming polling from the PC.

Here's the interesting part, which I noticed later.
A regular shutdown down followed by a regular boot of the PC didn't disturb the µC.
I therefore grabbed an old trusty RasPi with Debian Linux and set it up in a specific way.
Also connected the aforementioned powered hub and PICOs to it.

An external system engages a relay which in turn powers the RasPi for exactly five minutes.
Enough to boot into Debian, automagically start a terminal, verify that data from the PICO is still incoming, then shutting down.
After five minutes the relay disengages, thus removing any power from the RasPi for one minute.
(of course, the powered hub remains powered )
This six minute cycle repeats. Ten boots per hour…

Had it running for more than a day and more that 250 boot cycles and not a single problem occurred.
Then, just as a confirmation I disconnected the PICO and it crashed within a second.

That leads to one and only one conclusion:
Some USB status changes are handled properly, others are not handled and will crash and hard reset the µC.

Not my experience at all.

• MicroPython v1.25.0 (PIMORONI_PICOLIPO_16MB )
• USB & LiPo powered PicoLipo 16
• NP strip to show activity
• bolt_np.py script with a clear RED pattern that shows restart
• main.py imports the linked script

Runs rock solid through the following:

• Device USB connect / Disconnect ,
• USB Power Up / Power Down. ( Switch on USB hub)
• Cable -> MCU unplug / re-plug
• PC Cable to USB hub plug / unplug
• Power to hub disconnect / connect

It just keeps running 🏃‍➡️🏃‍♀️‍➡️🏃‍♂️‍➡️, as long as there is power from either source

Looking at the schematics the PicoLipo actually has a bit more hardware to make sure there is not just power, but it is stable/conditioned, and that seems to pays off in stability

I think your problem may be due to your boards getting spikes and powerdips on the VCC while connecting / disconnecting that you probably wont see them using just a multimeter.

that still does not explain why I cant reproduce the issue, with the same disconnection of the hub from the Win11 host
I did the same , though my host is Windows 11 and I know that there is a difference in DTR/RTS handling between *nix and Windows
I have seen these trip ESP32 into resets when mpremote was still using the default/naive *nix approach on Windows.
that was fixed quite some time ago but it may be an indication that perhaps the before/after states of the DTR/RTS signals may be worth looking onto

It's disconnecting the hub and reconnecting it.

other hubs , does the hub have power

there is a difference in DTR/RTS handling between *nix and Windows
before/after states of the DTR/RTS signals

Hmm, there isn't any RS232 involved here at all.
There's only a plain USB-FS integrated on-chip solution.
It's USB all the way from PC to hub to various devices including the PICOs.
And USB is per definition plug and play and not plug and pray.

And USB is per definition plug and play and not plug and pray.

well , that has surely always been the intent

A simple script from the REPL works too. So nothing to do with REPL

$ tio /dev/ttyACM0 
[tio 21:47:34] tio v1.32
[tio 21:47:34] Press ctrl-t q to quit
[tio 21:47:34] Connected
MicroPython v1.25.0-preview.4.g9ea8d2a03.dirty on 2024-11-13; WaveShare RP2040 Zero with RP2040
>>> 
>>> 
>>> import time
>>> cnt =0
>>> while True:
...     print(f'Hello at {cnt}')
...     cnt += 1
...     time.sleep(5)
... 
Hello at 0
Hello at 1
Hello at 2
Hello at 3
Hello at 4
Hello at 5
Hello at 6
Hello at 7
Hello at 8

[tio 21:49:24] Disconnected
[tio 21:49:43] Connected
Hello at 9
Hello at 10
Hello at 11
Hello at 12
Hello at 13
Hello at 14
Hello at 15
...