Workaround WebUSB DAPLink firmware issue

[microbit-carlos]

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:

• https://github.com/microbit-foundation/DAPLink/issues/17#issuecomment-1555034429

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.

[microbit-carlos]

@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
  • https://arm-software.github.io/CMSIS_5/DAP/html/group__DAP__Info.html
• 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]

Thanks @microbit-carlos

[microbit-carlos]

We talked about it with @abchatra and we think we should first do the following:

• Detect the issue and add it to the metrics
• Create a UX workflow to instruct the user to unplug and replug all micro:bit power sources

https://github.com/microsoft/pxt-microbit/assets/29712657/d9c210c3-aede-4e93-9854-05f6a76da0f1

[abchatra]

@jwunderl lets discuss this before starting the work.

[microbit-carlos]

Hi @jwunderl, have you had a chance to start looking into this? Let me know if there is anything I can clarify or assist from the DAPLink side. We are keen to have the UX workflow improvements ready for this release.

[microbit-carlos]

Another way to trigger this is by refreshing the MakeCode browser tab, as described in:

• https://github.com/microsoft/pxt-microbit/issues/5734#issuecomment-2299373434

[jwunderl]

Pointing at https://github.com/microsoft/pxt-microbit/issues/5734 and closing to aggregate related issues; as noted over there, a few fixes have made their way in to mitigate this by sending dummy commands / ignoring the failures which basically does this (just with no extra special cased logic to track previous commands), and seems to be covering the scenario (e.g. the makecode browser tab no longer reproduces to my knowledge)

[microbit-carlos]

I can still replicate this issue in the latest beta:

• makecode.microbit.org version: 7.0.29
• Microsoft MakeCode version: 10.2.23
• microbit runtime version: v2.2.0-rc6
• codal-microbit-v2 runtime version: v0.2.67

Here it shows the issue with the console log, after a while the flashing times out and it offers to download the hex file to the user's computer:

https://github.com/user-attachments/assets/9eb8ef64-2987-4c10-a833-7078568d8d76

Tagging @abchatra, as requested in the call earlier today. Let me know if you prefer this conversation to be moved to https://github.com/microsoft/pxt-microbit/issues/5734 (which already contains a few different webusb issues), or prefer to reopen this one.