Description

The Thingy:52 board is, so far, programmed via the exposed 10-pin header. That's convenient for deep system changes (where a debugger is good at hand), but impractical for quick experiments in the sense of "hey one of those is around, let's see whether RIOT is as nice as the stock firmware".

The device comes with a bootloader that allows flashing via BLE. (There's talk of flashing via Zigbee and Thread, but I s'pose those are different bootloaders). Firmware updates can be done using the nRF Connect or Nordic Thingy Android apps; the PC nrfutil command should be able to do that as well, but a) I haven't managed to get that to run with all its Bluetooth dependencies, and b) it seems not to use the PC's Bluetooth stack but an external device (?).

Useful links

• DFU instructions
• SDK download
• This is closely related to board suggestion: nRF52840-dongle #12189 (nrf52840-dongle), which uses the built-in USB bootloader but the same tooling and file formats.

Progress so far

My working assumption is that I can take thingy52 builds with the linker script set to nrf52840-dongle's, and use the same workflow for packing it up into a zip file. (The actual layout of the hex file is ignored; what matters is to get the start address right so that it actually points to the entry point. May need to change the layout with data from the Thingy SDK in project/pca20020_s132/armgcc/ble_app_thingy_gcc_nrf52.ld).

With the nrfutil in no working condition and uploading from Android, errors are a bit harder to track; adb logcat so far helped me find that the DFU code expects the binary size to be word-aligned, and inspecting the generated zip revealed that to whatever is in the .bin passed to it, three 0xff bytes are added that upset this original balance. It also showed that 0x00 is not a suitable SD version requirement here (0x98 is).

Currently, selfsigned objects with --enable-debug fail with OPERATION FAILED, those without fail with INVALID OBJECT.

Threats

• It may be that the bootloader is locked and only accepts signed firmwares.
• Application firmware version numbers seem to be required to be monotonous; this could prevent reverting to stock firmware and may require keeping track of firmware versions. (--debug-mode prevents that, but that could be blocked by the bootloader as well).