Hey Team Nordic, Can you explain to me: does the s130 soft device have the dfu bootloader already on it?

[tuf22191]

-Essentially I want to do a device firmware update on to the nrf51422 using my Android phone (the nrf applicaiton). I am using your sample code for a project that my company is doing (the license agreement is on top). Can you make a video of the example? -Bottom line is, I cannot get it to work: developer.nordicsemi.com/.../a00099.html

[Stefan Birnir Sverrisson]

Hi

Here is the bootloader documentation

There is also a bootloader tutorial available which is perhaps a good place to start.

[jeremysf]

It's all in the documentation, but here's the short version:

The bootloader is a separate (optional) program that you flash alongside your application and the softdevice; so there are either two or three programs your are flashing to your nrf51422. Boot loaders are custom applications you create, but most are very similar to the sample boot loader code provided by Nordic.

The softdevice gets control on boot, and if there is a boot loader, the softdevice will run that instead of your application. If there is no boot loader present, then the softdevice will just run your application. The soft device only knows if a boot loader is present (and where it is located in the flash) because you tell it by a setting in the UICR.

In "normal" operation, your boot loader does not do much except run your application, but the sample bootloader (and maybe your custom one) will check for a GPIO pin to be held high first, and if so, the boot loader will initiate the device firmware update process instead of running your application. In the real world, this might happen because a user is holding down a recessed "update" button when power cycling your device to initiate updating the firmware.

The DFU process is basically just a BLE service that implements a little protocol to receive a new application .bin and overwrite the existing application .bin in the flash. The boot loader's job is to implement that BLE service. The boot loader chooses to either sit in a loop implementing the DFU service, or to simply run your application instead depending on some condition like a GPIO pin being held high.

You could implement your own custom DFU service, but Nordic has a lot of sample code and tooling around theirs so it probably easier to use Nordic's than reinvent the wheel.

In addition to the boot loader implementing the DFU service, your application can also expose the DFU BLE service alongside your own services so your users can initiate a DFU at any time (i.e. meaning you don't need the user to hold down a button, etc on boot). Since it's not easy for your application to overwrite itself while running, at some point in the DFU process, your application will need to reset itself to give control to the boot loader to finish up the update process.

Many more details in the documentation as per Stefan's answer, but thought a 10,000 foot view / summary would help.

Please anyone jump in and correct any mistakes I've made in my summary.