Investigate M4 bootloader overwriting when not protected

[dhalbert]

The first batch of Metro M4's didn't have protected bootloaders. A number of people had their bootloaders damaged by some stray writes. We protected against this in the next batch by turning on BOOTPROT. But it would be good to know what bad code was writing to the bootloader block.

Here is a damaged bootloader, courtesy @jerryneedell:

UF2 Bootloader v2.0.0-adafruit.4 SFHWRO
Model: Metro M4 Express
Board-ID: SAMD51J19A-Metro-v0

m4flash.bin.zip

Compare with the original:
https://github.com/adafruit/uf2-samd21/releases/download/v2.0.0-adafruit.4/bootloader-metro_m4-v2.0.0-adafruit.4.bin

First 7 or 8 bytes have been zero'd, and at least the 512th byte has been zero'd (there are adjacent zeros, so can't tell). Those are the only changes.

Discussed in discord #circuitpython 4/24/2018

[dhalbert]

More notes from testing done a few weeks ago:

• This problem seems to happen even with an external CIRCUITPY filesystem, so doesn't seem likely it's filesystem code gone awry.

• Maybe it's not circuitpython at all, but something in the UF2 bootloader. I tried putting in some simple checks for writing to 0x0, but there was a catch-22 of uploading the bootloader itself. Didn't have time to figure out how to disable the boot protection and load via J-link, or else put in fancier checking to ignore the bootloader writing an update of itself to 0x0.

[tannewt]

@dhalbert This is fixed with the bootloader update right?

[dhalbert]

Woo, yes, this is fixed by adafruit/uf2-samdx1#111