microbit-carlos
commented
3 months ago @abchatra The general idea of the workaround (from https://github.com/microbit-foundation/DAPLink/issues/17#issuecomment-1555034429):
- When the response for the wrong DAP command is received, start tracking a history of received and expected commands
- Send a couple of innocuous different DAP command, the response value is not that important as we only need to track the command ID in the response message. For example it could read some DAP info
- If DAPLink sends a response for the previous command instead we can detect we are in this "one off" state
- Might be worth sending a couple of different commands to be 100% sure
- From this point forward on this WebUSB session we can send a dummy command in-between real commands, to counteract this "one off" issue
- So it looks like this:
- Send command 01 -> get bad response
- Send dummy command -> get response for command 01
- Send command 02 -> get dummy response
- Send dummy command -> get response for command 02
abchatra
There is at least one known issue with WebUSB failing that we can apply a workaround in MakeCode. If the micro:bit has a battery pack connected, when the USB cable is unplugged (in the middle of a WebUSB transaction) it can leave DAPLink in a bad state and WebUSB might stop working when the micro:bit is reconnected:
This will need a DAPLink firmware update, but a workaround can be applied to MakeCode as described in the DAPLink issue, which is desirable, as many user will never really update their firmware.