-
|
I'm encountering what seems to be a regression between 0.15.0 and 0.17.0 (updating to Pico SDK 2.1.0, which is on 0.17.0). Identical application code compiled against the two behaves differently. This is in an application driver, so not one of the standard classes. Everything works with 0.15.0. With 0.17.0, the device won't come out of suspend properly. Windows reports it in status 10 ("device reset") after the resume. The device side reports getting the resume signal, and it thinks everything's normal, but it's wedged on the Windows side. I've been poring over the library code trying to find a relevant change, but so far I haven't come up with anything, so I thought I'd ask here in case anyone has any insights into what might have changed that would have this effect. This ONLY happens when my application driver is in use. My device exposes a configurable set of HID, vendor, and CDC interfaces, and this doesn't happen when any other mix of interfaces is enabled. It only seems to happen when the interface for my application driver is present. So presumably it's something new that the built-in drivers are all doing and that I have to add to my application driver. But I haven't been able to identify the special new thing in any of the built-in drivers so far. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
Found it, by isolating the commit where it broke (3AB63FbC6). It's an error in the reworking of the vendor interface that broke vendord_reset(); the rework missed clearing the endpoint handles, leaving the connection in a corrupted state after the reset. Looks like it's a known regression, since it's been fixed since: 53989a9 "Fix vendor class reset." Applying that appears to fix it in 0.17.0. (I can't as a practical matter move to 0.18.0, because I'm using the Pico SDK, so I'm kind of stuck with the version they snapshot. I'll have to find some way to apply the fix within that constraint.) |
Beta Was this translation helpful? Give feedback.
Found it, by isolating the commit where it broke (3AB63FbC6). It's an error in the reworking of the vendor interface that broke vendord_reset(); the rework missed clearing the endpoint handles, leaving the connection in a corrupted state after the reset. Looks like it's a known regression, since it's been fixed since: 53989a9 "Fix vendor class reset." Applying that appears to fix it in 0.17.0.
(I can't as a practical matter move to 0.18.0, because I'm using the Pico SDK, so I'm kind of stuck with the version they snapshot. I'll have to find some way to apply the fix within that constraint.)