Add critsec to rp2040 xfer, check endpoint status #2474
Conversation
gemarcano
force-pushed
the
rp2040_irq_lock_fix
branch
from
ae077b0
to
bbf9ea0
Compare
gemarcano
force-pushed
the
rp2040_irq_lock_fix
branch
from
bbf9ea0
to
f2f0d25
Compare
gemarcano
force-pushed
the
rp2040_irq_lock_fix
branch
from
f2f0d25
to
5ee7ae9
Compare
|
This did not work so well for me as already mentioned there: #1764 (comment) |
- Implemented a critical section for the rp2040 port, which now prevents an IRQ from clearing the endpoint data structures while a transfer was in progress, which would then lead to a null pointer derefence. - Fixed a null-pointer dereference regarding ep->endpoint_control for endpoint 0, which does not have a control register.
gemarcano
force-pushed
the
rp2040_irq_lock_fix
branch
from
5ee7ae9
to
dcf472c
Compare
|
A lot has change in my project since I first came across this issue and now somehow even with the workarounds I had built-in I found a use case where I would always get So I eventually decided to checkout your branch gemarcano:rp2040_irq_lock_fix and sure enough it worked 🥳 Then I decided to remove the workaround I had in place to take care of the worst cases. It's basically filtering out some HID reports causing multiple USB remounts. Without it still did not panic but the USB connection seems to be broken somehow, not responding. I'll have to leave that workaround for now but it looks like I'll keep using your patch for the time being. |
|
As I was trying to rebase that on the tip of master I realised the tip of master works just fine too. Same symptom as described above. So I'm afraid I can't tell if that patch helps in any way after all. What's sure is that it works just as well as the tip of master apparently. I could rebase it with no conflict too. |
|
Tip of master still gave me that Panic after all, so I've started trying that patch again. Sure enough, I have not seen that Panic since. A couple of crashes and reboots maybe but possibly unrelated. |
Describe the PR
hw_endpoint_lock_updateis unimplemented for the rp2040 port. This PR takes a stab at implementing it. Without it, if the USB port is disconnected, say withtud_disconnect, a race condition can happen where a transfer is in progress and the USB IRQ can fire, callingreset_non_control_endpointsand leaving the ongoing transfer in a bad state, as it tries to access endpoint data structures that are now zero'd.While debugging that main issue, I also found some cases of the rp2040 port assuming that an endpoint data structure exists for all endpoints, which is not the case as endpoint 0 has none. I've also included a few simple fixes for these.
Additional context
I've documented a lot of my debugging attempts in this discussion: #1764
I'm not super familiar with the tinyusb coding style, and I'm not sure my lock implementation is right (very naive, likely bad reference counting, might need atomic_int instead of int?).