Close

"FU" DFU

A project log for Software Defined Lighting

Configure your light switches with Bluetooth LE

kevin-kesslerKevin Kessler 12/09/2016 at 18:090 Comments

My approach to this project is really to follow the "agile" methodology of a lot of little incremental firmware update, each adding a little more functionality. In order to do that, I really need to create some hardware, install it in a real location, and be able to update the firmware easily, ideally without having to tear apart where ever the device is located to access a programming header. The simple solution, of course, is Over The Air updates. When I was working with the ESP8266, a gentleman named Richard Burton created a nice bootloader, and it was easy to implement. You'd think with a big company Nordic Semi would have an easier implementation of Device Firmware Update, but you'd be wrong.

To be fair to Nordic Semi, the fact that the OpenMesh project forces me to use an old SDK (V 9.0 instead of the current v12) doesn't help matters, but the highly fragmented and complexly interrelated SDK is the root of the issue. Now the nrfOpenMesh project is actively working on DFU through the mesh, but it is unclear to me how you actually would use it. It seems their driving use case is a mesh member is connected to a computer through a serial port, and then, in some unclear fashion, propagate through the mesh updating all the other devices. I can't really follow how the updates are controlled. My main use case is just to update the firmware though BLE, and if I have to go to each individual device to do it, no big deal at this point, so I can safely ignore the mesh update. The DFU examples in the Nordic SDK do just this, so I decided that is the direction I would head.

It turns out that the Nordic SDK bootloader requires the Device Manager (which handles bonding information) that in turn requires the pstorage library, which changed how I store configuration information, and the pc-nrfutils tools current release is designed for the V12 SDK which supports signed firmware, so I had to checkout older releases of that utility to support my SDK, and so on and so forth down many rabbit holes of complexity I did not want to address at this point of my project. I've reached the point now, though, where I can successfully update the firmware, in somewhat of a kludgy fashion, so I have some hope. Right now, I need to connect to the device and start a DFU, the device restarts in DFU mode and the firmware update fails, but the device stays in the bootloader mode. I then reconnect to the device in bootloader mode, and I can flash it successfully. This is caused by connection information not being properly passed between the application and bootloader through the restart. The new firmware also wipes out the configuration of the device (the value handle which the switches and outlets communicate on), because the bootloader is not compiled to ignore these flash pages. I think both of these issues are solvable, and I think I might be getting close to building something that starts to do something useful.

Discussions