Add flash protection for bootloader/SD about adafruit_nrf52_arduino HOT 11 CLOSED

good point, basically, we will force some extra steps to perform SD or SD+bootloader upgrade either by serial/ota

from adafruit_nrf52_arduino.

Yeah, I think we should have two sketches ... one to 'unlock' the flash sections, and one to 'lock' them. We can compiled those down to .hex files and use them in the production tester, and when users want to update the SD and/or bootloader, they will need to run the unlock sketch so that it's clear they are doing something risky.

from adafruit_nrf52_arduino.

two sketch is a bit over protected. I am thinking to check some magic number, which is unique for each SD + bootloader combo --> user need to manually change it before packing it into zip package file. That could be check by the booltoader. Sort of unlock code, in general, we won't document it well, only ask when user asks perhaps :D

from adafruit_nrf52_arduino.

I think just locking and unlocking the appropriate pages is better using the standard SD calls, and we'll get a standard error back from the bootloader, and I can just add a sample sketch here like we do to toggle the NFC pins between GPIO mode and NFC mode, which requires writing to the config data: https://github.com/adafruit/Adafruit_nRF52_Arduino/blob/master/libraries/AdafruitFeather52Examples/Hardware/nfc_to_gpio/nfc_to_gpio.ino

This will also be less work to maintain since during production we just need to build those sample sketches to get a .hex file, and we can include that as part of the production process.

from adafruit_nrf52_arduino.

The main risk here is only for OTA updates, and to be honest most people won't be doing OTA updates since you can control everything from the Arduino IDE. OTA updates should only happen during a SD update, which should be rare since it's fairly stable at this point.

In that respect, I'm OK with lock and unlock sketches even if it's some work for end users, but I prefer something we can easily update if anything changes, and just recompile it.

from adafruit_nrf52_arduino.

The SD call with protect won't work with the two sketches scenario since it relies on the BLOCK PROTECT register which is clear upon reset, which our board needs to upload a sketch.

I think when starting up, SD already protect itself, that is why we need SD call to access the register (since it is used by SD as well). I may misunderstood your point though, but we want to protect user from Flashing an incorrect SoftDevice + Bootloader package (let's say from Nordic SDK) or even an stupid binary somewhere right ??

from adafruit_nrf52_arduino.

Yes. I'm afraid users will sent the wrong bootloader or SD, and then we need a JLink to debrick them, and it becomes a support headache even if the fault is essentially on the end users side but to avoid having to explain that, it's better to prevent people from doing stupid things in the first place. Thanks for the note on the SD BLOCK PROTECT, though. I'll have a look in the documentation at that.

from adafruit_nrf52_arduino.

I don't care what they do with the user app, BTW, since that's easy to change ... but if they corrupt the bootloader or SD, it becomes a product return or unhappy customer (even if it was their fault but they may not see it that way).

from adafruit_nrf52_arduino.

Lets move this over to email to avoid bothering everything email alerts with the discussion :P

from adafruit_nrf52_arduino.

yup

from adafruit_nrf52_arduino.

Apps will now be rejected OTA unless they target the right chip and SD.

from adafruit_nrf52_arduino.