-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
RP2040: USB data stopping #4190
RP2040: USB data stopping #4190
Comments
There is tinyusb PR that fix this issue recently, please try to manually update tinyusb to see if that fix your issue |
@DynamoBen Here is a build for the Pico that updates tinyusb to the tip of its Could you test with this and see if it improves things? Thanks. I only tested this enough to see that it presents the REPL and CIRCUITPY. |
@dhalbert Some progress, now my test app is locking up instead of USB comms stopping. |
Grabbed latest (adafruit-circuitpython-raspberry_pi_pico-en_US-20210223-cca6cfe) this morning and haven't see any problems. I'll check it again in a few hours and will post an update if it fails. |
Sadly USB comms are still stopping. I will continue to try future builds I guess. |
did you call midi read from your firmware application. The data is stored in midi fifo and need to be retrieved else it will be full and prevent further data transfer. It is mentioned in the hathach/tinyusb#618 discussion |
My tests thus far have been limited to transmitting MIDI. However I did update my test code to include a read but it made no difference. |
Note we have a TinyUSB update in #4245 |
I've been trying the latest build the last several days and the symptom now is the application not running ("locked up"). |
can you post your updated script to your first post, so that other could reproduce as well when they try to take a look |
Test code: code.zip |
There is several update for rp2040 lately. I will try to update & test with this next. Though I am using Linux, not sure if it has any differences. |
I keep trying the dailies and not much progress thus far. Normally I'd blame this on the computer but this is a stock Dell XPS desktop and I'm concerned that this isn't an isolated issue, albeit not widespread. |
@DynamoBen #4517 (now merged, so you can try "Absolute Newest") might be yet another reason for this problem, so if you wouldn't mind testing again, that would be great. |
Grabbed latest just now, no change in behavior. Runs for a little while and then stops. |
@DynamoBen I make an PR #4538 that should fix this issue, I have run your code on pico for an hour, and it still blink as normal. also attached the uf2.zip here firmware.zip for quick testing. |
@hathach it does keep blinking for a while but eventually disconnects. When the code is running MIDI eventually stops being sent. |
@hathach OK but I'm on Win10 |
Thanks for testing, seem like this is another the issue than the one is fixed in the #4538. Will reopen this |
It could probably an different issue, could you provide detail to reproduce the issue, I will try to see if I could figure out something. |
@hathach I can try testing with your UART debug output build on several different Windows machines. Would you want a Beagle trace if it does hang up? |
@dhalbert A beagle trace would be great, since it capture what actually happens. UART log does show how the stacks interpret the bus event. The more info the better PS: I am also trying to troubleshoot this, and will compile an new debug build for testing as well. |
@DynamoBen @dhalbert I tried my best to update tinyusb to address this issue. However, since all my PC cannot reproduce the issue. Would you mind trying this out again. zip contains uf2 for for pico and macropad with multiple debug level (0, 2, 3) . 0 is no debug just for verifying (in case debug log accidentally resolve it by slowing down cpu) |
I tried to reproduce on a Dell Optiplex 3020 last night with Windows 10 and failed. I will try an Intel machine with an older motherboard. Do you have any idea what this might be related to: is it Windows driver related, or might it be more USB controller related? Do you know if USB2 vs USB3 might make a difference? I can try various permutations, but I have many choices right now |
By failed, you mean you couldn't reproduce the issue and everything works well right !?
I couldn't reproduce the issue myself, and just update code where I think may be the issue. It is hard to tell for sure, If I am right, it is kind of race condition when host issue a bus reset e.g reset duration etc .. and cause the stack (with rp2040 port) to lock up. Theoretically, there shouldn't be any differences between using usb3 or usb2 host, though we all know it is hardly true in practical, there is always some diff, which cause trigger issue especially race condition. |
Yes, I failed to find a failure 😃 . |
I'm still seeing the issue, most interesting parts below. I used Debug level 2, because level 3 caused the USB driver to not be recognized. `USBD Xfer Complete on EP 85 with 4 bytes USBD Setup Received 80 06 00 01 00 00 40 00 USBD Setup Received 00 05 17 00 00 00 00 00 USBD Setup Received 80 06 00 01 00 00 12 00 USBD Setup Received 00 09 01 00 00 00 00 00 |
@DynamoBen the usb log look pretty normal, I should add timestamp to the log (will do it next), do you know how long does it take until the
Look like the issue is different than what I thought it is. Somehow the windows issue bus reset, and it is not related to the physical bus like suspend/disconnect. Probably windows driver think there is an issue with cpy and try to recover by reset it, however, the issue still exist (to windows), and it probably gave up afterwards. Maybe looking at host syslog would help, though I am not sure how to do equivalent |
@hathach It usually fails within 20 min, I can get some more exact timing if needed. Terminal continues after MIDI has stopped. I didn't try reconnecting the terminal. Pico is recognized still and no driver errors. It's been mentioned by others but I can use other USB MIDI devices without failure and I can run similar test code with a Teensy with no failure. It doesn't help with this specific issue but does mean there isn't a systemic USB issue with newer Dell computers (which seems to be the common thread). |
@DynamoBen device log look normal to me, I think we should look more at the host log/app. Can you tell me more about what does not work when the issue occurs. Original post said both MIDI and serial not working. Can you re-test it.
|
@DynamoBen sorry, it is my bad, the comment on the PR close this automatically, we merged since it contains other useful code even though it still hasn't fixed this one. Please provide your feedback as mentioned in above comment for further troubleshooting. |
Moving this to post-7.0.0. @DynamoBen we'd like your feedback on #4190 (comment) |
Will the current patch from tinyusb still be streamed into 7.0.0?
--
Rainer Paskiewicz
…On Mon, Aug 30, 2021 at 9:32 PM Scott Shawcroft ***@***.***> wrote:
Moving this to post-7.0.0. @DynamoBen <https://github.com/DynamoBen> we'd
like your feedback on #4190 (comment)
<#4190 (comment)>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#4190 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AANO2METZAMHBVX2QQUOU4DT7QWJZANCNFSM4XRHY5SA>
.
|
I am hoping to merge #5268 for the next release. |
I'm testing with latest right now, so far it's looking better. I should know tomorrow if the issues I've been seeing are resolved. I plan to do extended testing on two different Dell systems which previously exhibited the failure. |
Been running continuously for days, not sure what changed but things seem to be working now. |
@DynamoBen thank you for your feedback, lots of usb driver updated recently to make it compliance to USB test suite hathach/tinyusb#1059 , which help to review several corner cases bugs. It probably fixes this one as well (hopefully). When you are confident that the bug is fixed, let us know so that we could close this one. |
Looking good, I'm fine with closing. |
I created a test program that loops turning a MIDI note on and off. After running for a while (minutes not hours) I lose USB communications (both USB-MIDI and serial debug). I have the LED flashing to debug and it appears the loop is continuing it's just USB comms that stops inexplicably.
This is only reproducible on one of my Wins10 PCs (Dell XPS desktop) and the USB driver is still active when data isn't flowing. Further if I switch to a Teensy 4.0 running the same test (written in C++) USB comms continues indefinitely.
See forum thread for troubleshooting details: https://forums.adafruit.com/viewtopic.php?f=60&t=175112&p=854548 ]
[edit by dhalbert: on RPi Pico]
The text was updated successfully, but these errors were encountered: