I have already described my problem in the zigbee2mqtt forum, but there has been no response. So I'm trying here, because I assume that many people here have a similar setup (and in the end it is not a zigbee2mqtt related issue).
First of all, I am by no means a Linux expert; if anything, I have standard knowledge.
I’m posting this in the hope that someone with deeper Linux / Raspberry Pi USB knowledge can explain what’s going on. I’ve found a workaround, but I’d really like to understand the root cause — and I’m surprised this isn’t discussed more in the Zigbee community, because Raspberry Pis are so common.
Background / Setup
- For years I ran Zigbee2MQTT on a Raspberry Pi 3 Model B with Raspberry Pi OS Bullseye (SD card) without any issues.
- Coordinator / adapter: Texas Instruments LAUNCHXL-CC1352P-2 (Z-Stack)
Problem (after moving to Bookworm/Trixie)
I recently switched to Raspberry Pi OS Trixie (first on a new Raspberry Pi 4, later also tested on the Pi 3).
On both devices I saw the same behavior:
The Pi gets stuck in the boot process if the TI LAUNCHXL-CC1352P-2 is already plugged in (USB2 slot) during power-on.
If I boot the Pi without the coordinator and plug it in after boot it works (after stopping and restarting zigbee2mqtt).
At first I assumed hardware problems (I even returned the Pi 4 for service), but then I could reproduce it on the Pi 3 as well once it was on Trixie.
Workaround / Fix
Adding the following to /boot/firmware/config.txt under [all] made the system boot normally again with the coordinator plugged in:
dtoverlay=dwc2,dr_mode=host
After that, no boot issues any more.
My questions:
Is this a known issue with newer kernels / USB stack changes on Raspberry Pi OS (Trixie/Bookworm and later), especially around dwc_otg vs dwc2?
Is this specific to the LAUNCHXL-CC1352P-2 / Z-Stack (maybe older USB behavior), or have others seen similar issues with other Zigbee coordinators? All the Sonoff dongle users: No issues with booting with plugged zigbee device ?
Is dtoverlay=dwc2,dr_mode=host considered a “proper” fix, or just a workaround masking a deeper bug/regression?
I’m happy to provide more details (kernel version, dmesg excerpts, etc.) if helpful — I just want to understand why this happens and whether there’s an official recommendation for Zigbee2MQTT users.
Thanks a lot!
