Wireless DFU with gcc - Redbearlab BLE Nano

[kmoto]

Hi, I use nrf51822 with SDK9.0, gcc with makefile, and soft devices S110 or S130 on Windows. I would like to learn how to load firmware using the wireless DFU app from within the nRF Toolbox. I have been doing some searching but I am still somewhat confused about the requirements and proper steps for my particular setup.

I currently have no trouble loading firmware using the "drag and drop" method. For this, I compile my application to create an app.hex file. Then I combine the app.hex file with a softdevice hex file (such as s130_nrf51_1.0.0_softdevice.hex) using the "mergehex.exe" command. Finally, I drag the commbined hex file onto my nrf51822 board (Redbearlab BLE Nano). For this last step, the board is connected to an MK20 USB adapter that makes the board appear like an external drive (named mbed) on my PC. Then the board resets itself and my app is up and running. For more details on this method, see developer.mbed.org/.../

Some examples of things that I don't understand about using the wireless DFU:

1. Can I still use my combined hex file, or do softdevice and application need to be loaded separately? If separate, what order to load them? And are hex files appropriate?

2. Do I need to put a different bootloader on my board (using the drag and drop method) to enable the wireless DFU? If so, how/where do I get it/create it?

3. Can I use my current app (such as s110 heart rate example), or do I need to create a new app using the s130_with_dfu branch of the example?

4. Assuming I get wireless DFU working, can I still also use the drag and drop method? I so, will it overwrite everything and make the wireless DFU stop working?

Thank you for your kind consideration!

[Vidar Berg]

Hi,

1. Belive mbed programmer only supports programming of one merged .hex. This can be confirmed by programming the softdevice and application separately and see whether it works or not. If it is, you can merge softdevice and bootloader, then drag&drop it into the mbed disk. After the upload is complete it should start advertising as "dfutarg". This means that the device is running in bootloader DFU mode and you can connect and upload the application image using nRFtoolbox.
2. Yes, the bootloader example can be found in the following directory: \nRF51_SDK_9.0.0\examples\dfu\bootloader. Bootloader documentation can be found here.
3. Yes, the bootloader doesn't have any dependencies towards the application. However, you can extend the application to allow buttonless entry into bootloader DFU mode -> Adding DFU Service support to an application
4. Generally is not a problem, but I'm not sure if the mbed programmer does a complete chip erase or not. You would have to re-program everything if it does.