Fix abrupt USB disconnection leaving stale data in DAP queue buffers. #1090
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Clearing the buffers in the
USB_DISCONNECTING
state, which then moves to theUSB_DISCONNECTED
state.The
USB_DISCONNECTING
state was never used, in the current codebase nor the initial repo commit (well, second commit, first release): bdacee7 (this .patch URL is easier to search in-browser)It looks like this state might have been initially designed as a way to trigger a USB disconnection from the interface chip, as it manually set
usbd_connect(0)
to disconnect.As it was never used it's now the pre-disconnected state to run code only once on state change:
connected->disconnecting->disconnected
Fixes #1089
It was cleaner to do this as a "disconnecting" stage, instead of inside the current "connecting". This is because "connecting" runs during startup, which sets
usbd_connect(1)
, and that could have negative effects (port dependent) when switching from "disconnected" to "connected" as at that point USB is already fully running.