wasp-bootloader: a robust SoftDevice bootloader for PineTime

[danielt]

I got chatting on pinetime IRC channel (and the many bridged rooms using other protocols) yesterday evening and the discussion swung round to bootloaders... as I think all PineTime chats must eventually do ;-). So... having been encouraged to discuss the bootloader separately from the MicroPython stuff in the other thread let me summarize what I've been doing.

The very first thing I did when I got my PineTime was extend an existing bootloader to allow me to develop without relying on SWD. In other words I wanted my watch to be capable of BLE OTA updates *and* robust enough that it was difficult (although not impossible) for a broken application to lock me out of my watch.

https://github.com/daniel-thompson/wasp-bootloader

This is derived from the Adafruit nRF52 bootloader used on some of their feather boards.


The main changes are:

• It uses the PineTime display rather than LEDs to share status with the user
  
• It shows a nice pine logo as a splash screen ;-)
  
• It preconfigures the watchdog timer with a fairly generous (5 second) timeout
  
• It automatically enters OTA DFU mode on a watchdog reset
  

It is designed to pair with a special WDT feeding routine in the application. In C-ish pseudo-code it would look like the below. Note that writing button_tamper_check_ok() is a work-in-progress. It is very hard to tamper check on an nRF52 because the pin control is decentralized; we have to tour most of the peripherals and check it hasn't tried to "steal" pin 13 or pin 15 (for now I have just been careful when writing code to activate a new peripheral):

Code:

void feed_wdt(void) {
if (button_tamper_check_ok() && !button_pressed())
nrf_wdt_reload_request_set(0);
}

The recommendation is to setup a periodic interrupt (for a 5 second timeout this needs to be roughly every second) in the application and feed the watchdog from it. Normally it is not a great idea to feed a WDT exclusively from an interrupt (unless it implements a soft watchdog) but because the button press can be used to inhibit the feeding of the watchdog then this  essentially implements a long-press reset instead of a traditional watchdog.

The bootloader should work well for any SoftDevice based application providing the version numbers align (currently using S132 6.1.1). In principle it can also support other applications but the SoftDevice uses so much FLASH I think it would not be very practical. Various people on the chat caught me up on the discussions at FOSDEM and a bootloader needs to get a lot more sophisticated if we are to support OTA updates where the payload can use an "arbitrary" BLE stack.

However if you are already using SoftDevice this bootloader should work well... to use it all you have to do is relink you application with the flash size set 24K shorter.

At present the only missing robustness feature (that I have thought off) is providing deep sleep support. At present it is easy for an application to enter deep sleep without setting up a suitable wake up source. If that happens the WDT gets disabled and, worse, the system will use so little power that I suspect it could take over a month for battery to run out and make it possible to reboot the watch. Note that I don't think it is practical to prevent the app from sleeping but we can provide a bootloader service to set up a deep sleep in a safe and well tested way so the application can use that instead.

[Use this direct link if the forum video embedding doesn't work for you: https://www.youtube.com/watch?v=W0CmqOnl4jk ]