Skip to content
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

Interrupting USB connection can cause DAP response queue misalignment #1089

Open
microbit-carlos opened this issue Jan 28, 2025 · 0 comments · May be fixed by #1090
Open

Interrupting USB connection can cause DAP response queue misalignment #1089

microbit-carlos opened this issue Jan 28, 2025 · 0 comments · May be fixed by #1090

Comments

@microbit-carlos
Copy link
Contributor

microbit-carlos commented Jan 28, 2025

Tested with the latest code in the main branch and replicable with 0255 forward (not tested with older versions).

During a WebUSB connection, if the a transfer is interrupted before the DAPLink can send a DAP response (for example, by having a battery connected and yanking the USB cable), the next DAPJs connections process will fail (it establishes the connection and then sends a couple of DAP commands, like the SWJ_CLOCK).
This is because the DAP queue incorrectly responds to the first command with the unsent data from the previous connection. This leaves to the DAP queue to always respond with stale data, being "one off".

To replicate with a micro:bit V2.2 running 0256+:

  • Connect a battery pack
  • Connect the USB cable
  • Open MakeCode v7 https://makecode.microbit.org/v7#editor
    • The MakeCode editor constantly checks in the background if there is any UART data to read
  • Open the developer console
  • Connect via WebUSB and flash
  • Try multiple times: Disconnect and reconnect the USB cable
    • After inserting the USB cable, MakeCode should try to automatically reconnect WebUSB. Wait until the micro:bit logo on the "Download" button stops moving (it animates during WebUSB connection)
    • Every time the cable is disconnected at this point it should print an error in the console, this indicates a USB transfer was interrupted before the response was received.
  • Eventually, after a few reconnections the the WebUSB connection will throw an error on the console and won't connect.

We were familiar with this issue for a while, and was reported here:

@microbit-carlos microbit-carlos changed the title Interrupting a USB connection before device sends DAP response causes queue missalignment Interrupting USB connection can cause DAP response queue misalignment Jan 28, 2025
microbit-carlos added a commit to microbit-foundation/DAPLink that referenced this issue Jan 28, 2025
Clearing the buffers in the USB_DISCONNECTING state, which then
moves to the USB_DISCONNECTED state.

The USB_DISCONNECTING state was never used, in the current codebase
nor the initial repo commit (well, second commit, first release):
bdacee7

It looks like this state might have been initialy 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 ARMmbed#1089
microbit-carlos added a commit to microbit-foundation/DAPLink that referenced this issue Jan 28, 2025
Clearing the buffers in the USB_DISCONNECTING state, which then
moves to the USB_DISCONNECTED state.

The USB_DISCONNECTING state was never used, in the current codebase
nor the initial repo commit (well, second commit, first release):
bdacee7

It looks like this state might have been initialy 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 ARMmbed#1089
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant