microsoft
webusb not working after around 1hr
We use micro:bit in classroom settings with different Windows 10 Laptops with the app or chrome browser. While at the beginning of the lessons, all devices can be paired and also hex files downloaded to micro:bits without a problem, after around 1 hr into the lessons, it does not work anymore. microbit does not blink anymore but the software still says "dowload completed" or sometimes it just wouldnt stop downloading and one has to unplug the cable to stop it. They are still shown as paired/connected. Downloading the file and manually adding it to the drive works all the time.
This does not happen all the time but rather often.
If I know how to gather info, I could provide more.
Please check this information, especially under General, "If you have a battery pack...", which possibly applies even if you don't. https://support.microbit.org/en/support/solutions/articles/19000105428-webusb-troubleshooting
Adding some additional observations I've seen from a recent workshop:
- Paired fine the first time, but on subsequent downloads it didn’t recognize the micro:bit (even though the browser it showed as paired)
- Many teachers had the battery connected + USB cable when downloading - could be the problem?
- A handful of teachers were using USB adapters or USB hubs to connect with their computer's USB-C port - which may have been faulty
One thing to keep in mind in some of these cases:
If something odd happens and a WebUSB "full flash" download does not complete (for example, it gets stuck "downloading" and never finishes). If then the USB cable is removed or the window refreshed, it's possible that the majority of the programmed was downloaded into to the micro:bit flash, except for the UICR data (data at address around 0x1000_1000 so it's usually flashed right at the end).
In those cases, any subsequent WebUSB flashes will likely be quick/partial flashes, and if the partial flash routine doesn't check the UICR contents as well, then the wrong data in UICR (or blank data) could prevent the programme from running at all.
I haven't really checked the flashing code properly, but for example, if this bit throws away the UICR data during quick flashing (and it doesn't deal with it later on) we could end up with the right data in flash and the wrong data in UICR: https://github.com/microsoft/pxt-microbit/blob/974c9fad9f63555ca4f0fcaf0c829c3a69faf8f6/editor/flash.ts#L613-L616
Improvements in reliability have been made so i have not been able to reproduce random failures anymore; there is a potential memory leak described in https://github.com/microsoft/pxt-microbit/issues/5832 that i'm narrowing down, as well as some a few more possible cases in https://github.com/microsoft/pxt-microbit/issues/5734; closing this issue in favor of those
@jwunderl is the UCIR issue I mentioned in https://github.com/microsoft/pxt-microbit/issues/5699#issuecomment-2299220330 something you had a chance to look into?
Since you are already working in this area, making the updates to check the UICR contents will help in situations where the first flash fails for whatever reason, and then quick/paring flashing would always fail until a full flash is somehow triggered (via drag&drop flashing, or a future session has Makecode update that triggers a full flash).
@jwunderl is the UCIR issue I mentioned in #5699 (comment) something you had a chance to look into?
Since you are already working in this area, making the updates to check the UICR contents will help in situations where the first flash fails for whatever reason, and then quick/paring flashing would always fail until a full flash is somehow triggered (via drag&drop flashing, or a future session has Makecode update that triggers a full flash).
If this is a scenario you have seen reported, please file a separate issue for it; to my recollection I have not seen any issues or reports that indicated flashing issues that persisted through power cycling the micro:bit, which should be the case if that occurred. If this is primarily a theoretical issue I can look into it for a little bit after release
I've not personally seen it with the MakeCode editor, but I've seen it in the Python Editor, which does WebUSB flashing very similarly. Still unsure what causes the initial flash error, but subsequent issues with partial flashing was due to this UICR problem. The computers used in that workshop were painfully slow, so maybe that's a factor as well.
The reason I highlighted this UICR problem here, is because the original issue reported in this thread could be explained by this, as the symptoms match up:
- WebUSB flashing works until it doesn't
- WebUSB still connects successfully
- WebUSB flashing looks like it's completing successfully
- But the user programme does not run
- Using drag&drop to flash the device resolves the issue
I believe most of the other WebUSB issues we've seen throw errors during connection, or very early during flashing, so a problem where WebUSB flashing seems to work but the programme doesn't run could be explained by this.
The orange LED not flashing anymore during partial flashing could be interpreted as maybe being a different problem, but if the user programme is not running, then a partial flash doesn't have any new blocks to overwrite, so the orange LED doesn't really blink (or it's barely noticeable).
The other things that makes me thing it could be this problem, is that the user indicates:
...sometimes it just wouldnt stop downloading and one has to unplug the cable to stop it.
It's unclear what can produce the initial problem where the flashing process gets stuck, but by unplugging the cable before the download is finished (or if the flashing process never finishes to completion), then the device can end up in a state without the UICR data.
@jwunderl is this something you've had a chance to consider, or will this remain closed as a "no fix"?