-
Notifications
You must be signed in to change notification settings - Fork 0
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
After a failed Partial Flash full BLE DFU doesn't work #18
Comments
Technically the DFU works but it doesn't run the new software and to an ordinary user it will appear to have failed because microbit is stuck only being able to boot to pairing mode, because of the flashIncomplete flag saved in flash. |
Fixed this flag, waiting for the next dal release |
@microbit-sam You fixed RebootMode, not this issue. |
Right - yep |
TODO
|
That might help most of the time. However, if I understand what you're thinking, if the reboot to DFU mode fails or the client app fails to reconnect after the reboot to DFU mode, it will crash. We really only want to clear the flag after a DFU is started or at the end, but the DAL can't do that. If the flag is present and micro:bit boots to pairing mode, the app should be able to connect and ask for the flag to be cleared, knowing that it has just done a DFU, but that's still multiple BLE steps that could go wrong. What's really required is to arrange for a valid empty program to be present until the final partial flash packet succeeds or for the program to be marked as invalid somehow. Suppose when partial flash starts, the magic is replaced with a known bad-magic and then the address of the magic is stored in the flashIncomplete flag. At the end of partial flashing the correct magic is stored and flashIncomplete removed. The boot code would enter pairing mode if the flashIncomplete address and the bad-magic are both there. If the bad-magic isn't there, just clear the flashIncomplete address and boot as normal. The bad-magic would only be unaffected by smaller hexes and would be corrected by a DFU of the same hex. Would that work? |
At the moment from what I can see a failed DFU flash isn't handled at all, and I'm not sure it can be. How will the program even reach the point where it checks the flag if the DFU flash has failed? I might be missing something here, but I thought a failed DFU was unrecoverable without USB flashing Partial Flash -> Success -> Clears Flag -> Boots |
Once a DFU is started, failure does require a USB flash. As far as I can see, the only opportunity MicroBitDFUService has to clear flashIncomplete is before it reboots to DFU mode. After a failed partial flash, the client app will ask for the reboot to DFU mode. Rebooting breaks the BLE connection. If the app fails to reconnect and start the DFU, the DFU hasn't failed and both PF and DFU could be tried again, but if flashIncomplete has been cleared microbit will crash. |
True, but I'm not sure I see any value in adding a valid blank program in to fall back on though Where would we store the empty program? Within the DAL? Also if a micro:bit fails to Partial Flash and a DFU, maybe it's worth the user flashing over USB to refresh their device.. |
We can forget about a blank program. My last suggestion (starting "Suppose when partial flash starts...") is for a "bad" flag that will automatically get overwritten when a new flash succeeds. If you manage to boot into a corrupt program, I believe it's possible to brick the microbit so that A+B+Reset no longer works. The user can't USB flash if they only have their iPhone. |
Thinking about "Also if a micro:bit fails to Partial Flash and a DFU..." Perhaps it is a better option to leave the PF service as is and change the client app so that after a failed partial flash, it doesn't go on to try a full DFU. If the PF fails because of a problem with BLE, doing a DFU at that point is probably not a good idea. |
microbit is left with the flashIncomplete lock, which can only be removed by a partial flash or USB flash.
The text was updated successfully, but these errors were encountered: