Finding 3 from the checker in #11115. Not yet seen in the wild, but the path is real.
When core1 posts a USB event and core0 happens to hold the queue mutex at that moment, core1 falls into the pico-sdk blocking wait, which lives in flash. Core1 may not touch flash, so it hard faults and USB host goes silent. Timing-dependent and rare; a plausible match for "USB host just stopped" reports.
hcd_event_handler -> tu_fifo_write_n_access_mode -> mutex_enter_timeout_ms
-> time_us_64 / best_effort_wfe_or_timeout / __aeabi_lmul (all flash)
Possible fixes, needs a maintainer call: RAM-place the pico-sdk mutex/time helpers in link-rp2*.ld, or make the host event queue lock-free (core1 is the only writer, core0 the only reader).
Finding 3 from the checker in #11115. Not yet seen in the wild, but the path is real.
When core1 posts a USB event and core0 happens to hold the queue mutex at that moment, core1 falls into the pico-sdk blocking wait, which lives in flash. Core1 may not touch flash, so it hard faults and USB host goes silent. Timing-dependent and rare; a plausible match for "USB host just stopped" reports.
Possible fixes, needs a maintainer call: RAM-place the pico-sdk mutex/time helpers in link-rp2*.ld, or make the host event queue lock-free (core1 is the only writer, core0 the only reader).