After a failed Partial Flash full BLE DFU doesn't work

[martinwork]

microbit is left with the flashIncomplete lock, which can only be removed by a partial flash or USB flash.

[martinwork]

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.

[microbit-sam]

Fixed this flag, waiting for the next dal release

[martinwork]

@microbit-sam You fixed RebootMode, not this issue.

[microbit-sam]

Right - yep

[microbit-sam]

TODO

• Clear flashIncomplete flag in micro:bit DFU service

[martinwork]

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?

[microbit-sam]

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?
At that the point is the only option to flash via USB - if so the app will have to inform the user rather than the micro:bit

I might be missing something here, but I thought a failed DFU was unrecoverable without USB flashing

Partial Flash -> Success -> Clears Flag -> Boots
Partial Flash -> Fails -> Partial Flash -> Success -> Clears Flag -> Boots
Partial Flash -> Fails -> Full Flash -> Clear Flag -> Success -> Boots
Partial Flash -> Fails -> Full Flash -> Clear Flag -> Fails -> Needs USB Flash

[martinwork]

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.

[microbit-sam]

True, but I'm not sure I see any value in adding a valid blank program in to fall back on though
If the micro:bit can't reconnect it will either enter the valid empty program or crash, but it should still be possible to enter BLE mode from either state (reset and both buttons)
Or would empty program reset itself into BLE mode automatically?

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..

[martinwork]

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.

[martinwork]

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.