Flashing target hex file in MAINTENANCE mode soft-bricks micro:bit since bootloader 0241

[microbit-mark]

Description: We often get user reports of micro:bits "stuck" in MAINTENANCE mode, that can only be returned to MICROBIT mode after they flash a DAPLink interface hex.

We believe the cause is due to the relative simplicity of entering MAINTENANCE mode by accident, eg. by pressing reset when inserting the USB cable, and then flashing a target micro:bit hex in this mode. When this happens, it is not obvious to users why the micro:bit is not flashing their programs anymore, or how they can fix it

Steps to reproduce the behaviour: Using an out-of-the-box micro:bit 1.5 with bootloader 0243 (the default for the 1.5 revision)

1. Put the device into MAINTENANCE mode
2. Flash hex from microbit-heart.hex.zipto device
3. Device restarts in MAINTENANCE mode
4. Unplug and replug USB. The device still starts in MAINTENANCE mode

Expected behaviour: Flashing a target hex whilst in MAINTENANCE mode should generate a FAIL.TXT saying "The hex file you dropped isn't compatible with this mode or device. Are you in MAINTENANCE mode? See HELP FAQ.HTM"

This was the behaviour as designed with the BBC and released in DAPLink Bootloader 0234 for all the original micro:bits.

Additional information: It looks like this behaviour is by design and was introduced at 0240 in https://github.com/ARMmbed/DAPLink/commit/c130e3af71df11322565edcba246596538c1960b as a means to allow 3rd party images to be flashed in bootloader mode.

We have tested this up to version 0254 as well and the issue is still present.

To resolve this, could DAPLink re-enable interface image validation and if so can it be bypassed via automation? So that, for example, if J-link wants to make their software available to the micro:bit firmware chip, they could either add the same validation or instruct the users to copy the hex file into the MAINTENANCE drive while the reset button is pressed.

If making this change would affect other DAPLink boards, could this validation mode be enabled on a per-board basis, or via some type of configuration?

[Ninerian]

@microbit-mark Hi can you give me a short description what to do if this happens? I have a new microbit board which is stuck in Maintenance mode and gives me Out of Bound Errors when I try to flash a firmware.

[microbit-mark]

@Ninerian Could you send me an email on help@microbit.org with a copy of the DETAILS.TXT file from the board when it's plugged in on USB? We can then do some troubleshooting and work through the issue.

[flit]

We'd be happy to have a config setting to restore the validation. For micro:bit the default would be enabled, for other builds disabled. However, the micro:bit Foundation will have to implement this behaviour; we don't have resources to do it (our limited time is focused entirely on gcc enablement at the moment).

Fyi, automation is enabled by default now.

For the micro:bit v2 there is the possibility of additional or different validation based on the fact that the target nRF52 is an M4 whereas the KL27 HIC is an M0+. Thus there are vector table entries that should be zero only for valid DAPLink firmware. @gerargz may have already implemented something like that? Not sure if it's only for the interface though.

[tran-dan]

I can't fix this maintenance (G:), please help me ! thank you.

[carlosperate]

@tran-dan could you send this info via email to help@microbit.org? Rather than derail this thread we'll be able to better help you over there with the first steps to debug this issue.