We now have support for Firmware Over The Air (or FOTA for short) for the mKit platform (actually anything based on the nRF51822). This means that you can program the nRF51822 without going through the mbed interface chip over USB. No need for cables except for an initial install of the bootloader image (or as a fallback). And you can get console output over the air as well.

Binaries built for FOTA need a minor change in the toolchain (they don't need to be combined with the softdevice), and so we've cloned the build platform into a 'shadow' platform for FOTA on mKit. You can access this shadow platform by following this link. We should be creating similar FOTA-clones for other nRF51822 platforms in future.

Has anybody gotten FOTA to work on the nRF51822?

To be crystal clear this is what I'm trying and it is my best understanding of the directions at: http://developer.mbed.org/platforms/Nordic-nRF51822-FOTA/

Compile the default application into "BLE_Default_APP_NRF51822_OTA.bin" by setting 'nordic nRF51822 FOTA' as target and hitting compile. As best I understand this binary is the default app and the bootloader bundled together, which I have tried to upload to both MBED LOADER and regular MBED (I do not understand what the "initial image" link is.. I have tried downloading the hex file and uploading, once again, in both bootloader mode (holding reset while plugging in), and non bootloader mode. The big red flag is that that file is 279KB which is certainly bigger than the capacity of the nRF51822 device.

At the end of the day I'm way stoked about the FOTA feature for developing and debugging wirelessly (i.e. with an android tablet) but I just can't get it to work. I've tried I think every imaginable permutation of downloading bootloader and application onto the chip using FOTA and non FOTA as target. I have never gotten a successful connection after uploading the FOTA *.bin file onto the device (and I would imagine this is where the money is). I have been able to get the "defaultApp.hex" (hex are produced for non FOTA target and bin by FOTA target) onto the device with the standard bootloader, and in this way I am able to connect to the device, get the "you may now use DFU to upload" message, however when I try to upload it says "Connecting [...] Uploading [...] 'Error during firmware upload. Data could not be sent - failed!!!' "

P.S. when I do upload the defaultApplication_OTA.bin to MBED LOADER I see LEDs 1 and 2 alternating. After unplugging and replugging it, not holding reset, the device no longer enumerates as MBED. In this case however it is not visible to connect to.

Thanks in advance

Hello Nathan,

Please install the default bootlaoder app (initial image) from above. Please do not build the default app using the online toolchain; if you do, it will not get combined with the bootloader and you won't get FOTA functionality.

Firmware updates using FOTA require the bootloader. The online toolchain for nRF51822 combines applications with the soft-device (but not the bootlaoder), and that's fine for stand-alone applications which don't need FOTA.

The sources for the default app were released only as reference.

Hello Rohit,

Your response time was truly incredible! Yes this was my initial interpretation however I have had any luck actually uploading an app that the toolchain outputted (some *_OTA.bin file). Is the initial image meant to be uploaded to MBED or MBED LOADER?

I find that I can upload to MBED but not MBED LOADER as follows... /media/uploads/nargetdev/screenshot_2014-10-27_04.18.37.png

When I hit DFU on my 'master control panel' I receive the following two messages for uploading the FOTA shadow generated *OTA.bin file, and the normal nRF51822 target *.hex file respectively.

• .bin file: /media/uploads/nargetdev/screenshot_2014-10-27_04.27.44.png

• .hex file: /media/uploads/nargetdev/screenshot_2014-10-27_04.28.25.png

Am I right in assuming I should be building *.bin files using the FOTA shadow for uploading OTA? I've noticed that when I try to upload from Android it simply says that I can't use bin files.

Thanks so much!

Hmm. A few points of clarification are in order.

Intel Hex files offer a human readable view of a binary; and so their size is often double the actual amount being flashed. So if the size of your .hex file exceeds the size of the internal flash, that by itself isn't cause for alarm. Every byte of the binary gets represented by two hexadecimal characters; and there's some metadata on top.

MBED LOADER is the name of the virtual drive which allows programming the interface chip. You should not be programming it at all. You need to program the nRF51822 target, which appears as MBED.

I'll answer the rest in a few minutes

Nathan,

You seem to be using the Windows version of the master-control-panel FOTA tool from Nordic; and by the looks of it, it doesn't support .bin files. How are you driving the windows update? going through the dongle? we're curious.

Please note that FOTA binaries don't need to be combined with the soft-device or the bootloader; and we generate .bin files because they're compact; and with FOTA going at 2KB/s, it would be nice to send .bin files over.

I believe Nordic's MCP app on Android (and even iOS) supports .bin files for FOTA; could you please re-attempt with those apps instead of the widows MCP?

We care very much to support your use of FOTA; please provide us with feedback about your experience.

The Android MCP doesn't support .bin. Neither does the Beacon demo app.

Unless I'm missing something in the s110 docs and bootloader sources, the OTA protocol is binary-only, so the app is responsible for parsing the .hex. If that's the case, then there's no advantage to .bin for DFU.

we're looking into this as best as we can; and it is very likely that we'll switch to using .hex files for OTA builds of applications. In the mean time, please convert the .bin files into .hex files using some tool like srec_cat (if you choose to do so, please remember that you need to offset your .bin files with 0x16000. So, I belive the srec_cat options would look something like:

srec_cat input.bin -binary -offset 0x16000 -o output.hex -intel

We'll do our best to update the toolchain shortly.

What other differences are there in the FOTA platform? If that's all there is, it would be better if the DFU app (MCP or whatever) could handle extracting the app section from the .hex and send just that payload, and keep the platforms as they are.

@Andrew Litt: FOTA applications automatically have the DFU service included, which is what you'd expect so that applications should continue to remain updatable; otherwise, you're correct in pointing out that the FOTA driver app could extract the relevant app-bits and could hide the differences between FOTA/non-FOTA build platforms. Perhaps we should should require users to include DFUService explicitly and combine the platforms.

thanks for bringing this up.

I don't think developers would be required to include DFUService in their apps unless they want to start FOTA wirelessly. There's always the trigger button that can be held during power-up. Since DFU is a potential security risk, some users might prefer physical interaction to trigger DFU.

Going down that path, would it be possible in the future to make the DFU bootloader part of each platform and add it to every .hex? CMSIS-DAP downloads would then always populate the sd, app, and bootloader, while FOTA as described would only update the app. The minor differences that the bootloader cares about (button to trigger POR-time DFU, LED, LFCLKSRC) could be inferred from the platform target headers. It would make CMSIS-DAP downloads 16K longer, but would make it unnecessary to maintain separate starter bootloader images and sources and let developers switch to DFU-only development with minimal confusion.

As mentioned above, the DFU GATT service is only required if you want to enable DFU mode over the air from the Central device side. That's a useful scenario when you want transparent firmware updates from the app side, but isn't strictly necessary (or perhaps even desirable) in every situation, and there are still several ways to enter DFU mode without the service. A special command can be implemented on the nRF51822 to trigger DFU mode on the peripheral side, for example, or a HW button can be used to trigger it.

I have a hardware platform without hardware button, so a feature which ensures that firmware compiled by the user (using the FOTA build server) include the DFU service is useful to me.

I can also envisage plenty of scenarios similar to mine (for example, consider the case of devices which need to be sealed / potted for low-volume waterproofed applications).

On the other hand, abstracting away too much configuration into the hidden build server settings is a headache for those of us who are testing hardware platforms which are not yet in the list of supported platforms on mbed.org...

Will this work on Arch BLE too?

Hi Hilton,

FOTA works on the Arch BLE too. We customize a bootloader (https://github.com/Seeed-Studio/nrf51_dfu_bootloader) based on the works of Nordic and Rohit. You can download the bootloader from the github release page, compile your own bootloader with make (Makefile) and gcc arm embedded toolchain.

To use the bootloader:

1. Drag-n-Drop a hex file with Nordic's softdevice into the Arch BLE. Any hex file generated by the online compiler for Arch BLE target would work

2. Drag-n-Drop the bootloader hex file into the Arch BLE

3. Extract an application hex file from your hex file generated by online compiler, which contains Nordic's softdevice and the application. Use the following command:

srec_cat {application_with_softdevice.hex} -intel --exclude 0 0x16000 --exclude 0x10001000 0x10002000 -o {application.hex} -intel --line-length 44

replace {application_with_softdevice.hex} and {application.hex} with yours.

4. Pull down Arch BLE's p1 and reset to boot into bootloader. If your application has DFUService, you can trigger the bootloader using Master Control Panel. See Rohit's note

5. Use Master Control Panel on Android, iOS or Windows to upload your application hex through Over-The-Air

Thanks for your reply Yihui,

Just to clarify the steps :

a) File in step one is any app from the online compiler, i.e: https://developer.mbed.org/media/uploads/rgrover1/ble_default_bootloader_app.hex

b) File in step two is Seeed's bootloader i.e: https://github.com/Seeed-Studio/nrf51_dfu_bootloader/releases/download/v0.1/arch_ble_bootloader_v0.1.hex

c) step three is essentially extracting the application part out file from step one creating a new file, called (anything really but application.hex is typical)

d) I have the nRF toolbox app but wasn't sure what "Pull down Arch BLE's p1" meant? I did reset it using the button and power-cycled multiple times but the DFU app could not find a BLE device (the only way I could get it to do that was repeating step one however I assume that step two overwrites step one)

Hi,

I apologize for the delay in creating a simple FOTA process for mbed users. There's already a default app which combines the soft-device, bootloader, and some dummy application offering the DFU service. You could easily get started with this and arrive at a FOTA-ready initial app.

FOTA applications don't need to be combined with the soft-device; this is because the soft-device remains unaltered in the process.

There is a mbed platform to build for FOTA targets: http://developer.mbed.org/platforms/Nordic-nRF51822-FOTA/. The advantage of using that platform is that applications get combined with the DFU service automatically; this helps keep the FOTA capability alive in the succeeding app. Unfortunately, mbed's current FOTA platform produces .bin files, which although being smaller don't work with the Nordic tools. We're nearly at a point where the online build system will generate .hex application files for the FOTA platform. In the absence of that, you need to convert your .bin files into .hex (together with adding the correct application offset). This can be done with the following:

srec_cat your_app.bin -binary -o your_app.hex -intel -offset 0x16000

As a work-around, you can also generate new successor .hex apps by extracting them from the .hex files generated by selecting non-FOTA platforms from the online IDE. This is what has been described by Yihui Xiong above. Please note that in that case you'll need to explicitly add DFUService to your app to allow FOTA continuity.

We're also developing an iOS app (and later an Android app) to drive FOTA; but that will take a few weeks to show up.

You can learn more about FOTA from http://developer.mbed.org/forum/team-63-Bluetooth-Low-Energy-community/topic/5169/

rohit.

The mbed FOTA platform for Nordic now produces .hex files. No need for the above steps. Just start with the default app (above) [or find a way to install the bootloader and the softdevice], and then you're set to go with FOTA. We'll soon be releasing an iOS app to drive FOTA; with an Android version following soon.

rohit.

Hi Hilton,

The bootloader (arch_ble_bootloader_v0.1.hex) will check the status of pin p1, it will start DFU process when p1 is connected to GND.

Yihui

I've finally gotten FOTA to work, and have done some sanity checks by flashing my LEDs in different patterns with different firmware uploads. I think it should be noted that I have only succeeded on windows using Master Control Panel. Also the upload fails every other time (consistently I get some "Error uploading [...] !!!" message the first time I try and then the second time it succeeds). Also even though I've gotten it to work once I can no longer get it going again. Additionally I have never succeeded on Android.

I think the FOTA instructions could be a little more clear. Specifically specify that the "initial image" is the bootloader and the application (Default Application), and explicitly tell the user they should be uploading this initial image to start with, and not the Default Appication alone. I know it seems obvious, and it is obvious to me now that I have done a bit of reading, but I think this could be more straightforward. For one I think it would be more sensible to change the "initial image" link to be a direct download, rather than linking to a page with the text representing the *.hex file (not all users will know to click "save link as...").

Lastly, do you think perhaps that because I haven't explicitly uploaded my softdevice to the board, this may be part of why it is not functioning properly in my Android Master Control Panel (it shows up, but when I try to connect I get a blank screen)? Is the softdevice included in "Default App"?

Thanks

P.S. Is there a way to have access to my dropbox files for the DFU on the iOS Master Control Panel? Seems simple but I couldn't figure it out.

Hi Nathan,

Thanks for your feedback. You should see improvements in our documentation shortly.

Please refer to the following video for a demonstration of FOTA using Nordic's MCP (starting around offset 2:00 in the video) https://www.youtube.com/watch?v=54V2_4TR9Wo

In the second stage of the FOTA process, when the device is running the bootloader and shows as DfuTarg, connecting to it requires a little longer in 'service-discovery'; and may even require pressing the 'connect' button. Otherwise, I am able to drive FOTA without any problem.

We'll try to change the "initial image" link to be a direct download.

The SoftDevice is included in the 'initial image'.

We're working on an iOS app which will allow you to pickup firmware files from Dropbox and drive FOTA seamlessly. It is ready to be released and is going through last minute validation.

Yes I've seen that video before, it's a cool demonstration. (By the way what is the model of the smaller device? This smaller one also runs mbed?)

I'm able to connect to default app, and I'm able to see my DEBUG messages through UART (that's a very cool feature). Also most of the log messages look normal, so I think the connection is fine, but let me describe what happens when I attempt a DFU upload:

The screen changes to the graph > "Connecting..." > "Starting DFU..." and then back to the previous app (DefaultApp in my case). The log output goes like this:

Error (0x85): GATT ERROR (or otherwise Error: 133)

I've made sure to add in the DFU service in the app I'm trying to upload (the BLE_HeartRate app), and compiled using FOTA platform.

Thanks in advance

@Nathan: The small coin-cell shaped device in the video is the smart-beacon kit from Nordic. It doesn't have the mbed interface chip, so it isn't an official mbed platform. We're going to release a external programmer to target the smart-beacon kit through a USB->SWD adaptor.

If you build using the FOTA platform, you *do not* need to explicitly include the DFU service. It is implicit.

Are you able to drive FOTA using Nordic's MasterControlPanel?

Hi, I realise this is old thread, but I'm trying all avenues to get a FOTA problem resolved.

I'm using the nRF51-DK, which has different chip (memory) to the nRF51822-mkit, and am trying to get an application to compile using the DK-FOTA platform, but keep getting error saying device.h not found. If I change to the nRF51822 FOTA platform then compiles ok, so there's something different in the nRF51-DK FOTA platform that's causing compile failure.

Any help is appreciated

@Andrew: I've replicated this build error by compiling BLE_iBeacon using nRF51-DK-FOTA platform. The build fails for me saying device.h isn't found. We'll look into this ASAP. Many apologies for this.

Thanks for (super) quick reply, you are indeed a true legend of the forums

device.h not means that you have to update the mbed library in your program to support this platform. Hope this helps.

Cheers,
Mihail

@Mihail: I believe there's more to this issue than having to update the mbed library. I've updated to the latest of the mbed library for my iBeacon application. I can build correctly for the nRF51-DK platform, but not for the nRF51-DK-FOTA. 'device.h' is missing only for the '-FOTA' version.

As I am having the same issue, I looked into the problem and found out that apparently the name of the platform (with "-FOTA") is not listed in the mbed library compiler/linker scripts so it does not recognize the correct path to a couple of folders inside mbed (among others the one where "device.h" is located). Is there a way to access and modify compiler/linker scripts on mbed platform?

@Andrew, @Luke, please discontinue using the *-FOTA platforms. Instead, with the nRF51-DK platform, you'll find that there's a drop-down at the top-right of the IDE (next to the platform-name) and you can select 'App for FOTA' to build a binary for FOTA. There are other options: 'App with Bootloader' (which is the Soft-device+app+bootloader combination) and 'Default' (which is the softdevice+app combination).