-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
USB MSC has some sort of race condition #2322
Comments
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 EDT: the following kind of works with FreeRTOS (since
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 raspberrypi/pico-sdk#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 repeat
picotool 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
The text was updated successfully, but these errors were encountered: