You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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".
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:
The text was updated successfully, but these errors were encountered:
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
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
FixesARMmbed#1089
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
FixesARMmbed#1089
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+:
We were familiar with this issue for a while, and was reported here:
Opening this issue upstream to open a PR and link it.
The text was updated successfully, but these errors were encountered: