Open byteit101 opened 11 months ago
I think I am also seeing this issue on a custom STM32H7 board.
For a variety of reasons the host resets the bus (in my case simply sending 0 bytes to a read10 request triggers this with a windows host after a while).
The DCD_EVENT_BUS_RESET message is immediately followed by a DCD_EVENT_XFER_COMPLETE on an IN endpoint, and the subsequent TU_ASSERT(driver,) fails.
I can also reproduce what @jncronin is describing. If I have high load on my STM2U585 MCU, probably some response is handled too late, which results in a bus reset from the host. Since this DCD_EVENT_BUS_RESET resets the device info in _usbd_dev
, but the event queue is not cleared, the already present DCD_EVENT_XFER_COMPLETE is read in the next round and tries to find drivers in an empty _usbd_dev
, which fails into the Assert.
EDT: the following kind of works with FreeRTOS (since osal_semaphore_reset
expands to xQueueReset
)
--- a/dwc2/device/usbd.c
+++ b/dwc2/device/usbd.c
@@ -585,6 +585,7 @@ void tud_task_ext(uint32_t timeout_ms, bool in_isr) {
case DCD_EVENT_BUS_RESET:
TU_LOG_USBD(": %s Speed\r\n", tu_str_speed[event.bus_reset.speed]);
usbd_reset(event.rhport);
+ osal_semaphore_reset(_usbd_q);
_usbd_dev.speed = event.bus_reset.speed;
break;
Of course there will still be a reenumeration etc. but the device keeps on living and Windows seems to find it again as well.
Operating System
Linux
Board
Raspberry Pi PICO (RP2040)
Firmware
https://github.com/byteit101/test-tinyusb-pico
What happened ?
panic/assert/exit calls sometimes, but not always, on writes (I think?).
I have confirmed it on Debian 10,
Linux 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux
I haven't seen it on a "blank" flash (no filesystem)
I have confirmed it with G++ 8.3 and G++ 12.2 (the latter requires uncommenting
target_link_options(${PROJECT_NAME} PRIVATE "LINKER:--no-warn-rwx-segments")
in the CMake file)I have reported this downstream as https://github.com/raspberrypi/pico-sdk/issues/1523
How to reproduce ?
Ensure you have a 1.5.1 PICO SDK setup in your environment.
In one terminal,
tio /dev/ttyACM0
(or some other auto-connecting serial console) Now, watch dmesg -w or such, and repeatpicotool reboot -f
. Sometimes it will be ok and you will see the Test Flash load, and remain loaded, and tio serial connection remain connected.Othertimes, it will first do that, then after a few seconds, it will disconnect serial, and reload into the RP2 bootloader drive. This is the failure condition:
Debug Log as txt file (LOG/CFG_TUSB_DEBUG=2)
Using tinyusb 0.12, I got this log sequence, culminating in an assertion failure:
In contrast, successful Set Address looks like
The reordering, combined with the fact that it's highly irregular, sometimes failing for 5 reboots in a row, then succeeding for 50%, then succeeding for 10 reboots in a row, makes me think this is some kind of race condition in the MSC TUD driver.
The stack trace was usbd_control.c:171, called from usbd.c:562
I updated TinyUSB to 0.15.0, and now get:
Screenshots
No response
I have checked existing issues, dicussion and documentation