This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Over the air bootloader

Dear support,

We are in the design stage for a BLE application. We looked at different options. Although the NRF51822 seems better in specs. The TI parts CCxx offer this bootloading over the air option which is very attractive to us as we can skip some hardware parts like USB connector etc. Are there developers busy with a Nordic solution which uses over the air bootloading ? Is this technical possible ?

  • All our sales people should be familiar with the concept of a bootloader. Please see my private message, Bikkel.

  • As I said above, upgrading the application is most definitely technically possible, and it shouldn't be very hard to make yourself if you are familiar with the ARM Cortex M0 and BLE. The only bootloader solution we currently have is the UART bootloader contained in SDKs 4.2.0 and 4.3.0.

    I cannot say anything about what we will and will not make here, but your sales representatives might have further information to share.

  • Whilst it is very attractive, I would say that you absolutely, categorically want Nordic to take their time making sure that it works flawlessly. A bricked boot loader in the field on a consumer product would be a disaster, for example.

    My experience with Nordic so far is that they're fairly conservative in introducing new features, which is a Good Thing(tm) in the long run. :)

    Whilst OTA updates sound like a great feature, and they are, you should be aware of some of the [current] fundamental limitations of BLE. Namely, if you think you're going to be achieving anything near ~250kbps in throughput whilst updating the firmware, you're sadly mistaken. Real world performance will be a couple of kilobytes a second -- on the verge of what is tolerable to the average consumer.

    There's working groups within the Bluetooth SIG whose proposals/work will alleviate this in time, though.

    -m

  • Good point Marc this transfer speed. That is why it is important to pack such a feature in the BLE stack itself. Ideally you want as much fixed (proven) code in the BLE stack and keep the user application small. The first price would be if the uploading is handled by the BLE stack itself. Even if you mess up the user code you can still upload new code. I don't know if that is possible.

  • Just for the fun of it, I just pushed my own bootloader projects to GitHub. Please note that this is my private hobby project, and not at all endorsed by Nordic as a company. I've done it in my spare time, just to see how to do interrupt forwarding and flash writing. It uses a different concept entirely from the official bootloader, which is probably the cause of it being quite slow. It also uses interrupt forwarding, and is hence not dependent on the softdevice, but instead introduces some additional interrupt latency (< 10 instructions).

    I don't really have any plans on following this up any further, but I thought I could push it out there so that you can have a look if anyone wants to do something right now and need somthing to look at. Feel free to fork the repository, submit pull requests or just pull the code apart. :) But before doing anything long-term with it, I'd recommend you all to discuss the concept of a bootloader with your Nordic sales representative to ask about our (official) future plans.

    I'll also be gone for vacation for the next 3 weeks, and will most likely not be able to participate much here. Since they are hobby projects, noone else knows these applications, so don't expect any help through official channels. :)

Related