S110 v8.0.0 softdevice size and DFU update

[Clem Taylor]

With S110 v8.0.0's size increased to 96K, I'm concerned that my current memory layout is going to prevent me from upgrading to a future softdevice.

It seems that the only safe way to do a major softdevice version update is to upgrade both the softdevice and the bootloader at the same time. That seems to be the case for a 7.1.0 -> 8.0.0 and I'd assume it would be the case with future major versions.

I'm currently using 32K for the bootloader and 2K for the pstorage parameters, so with 8.0.0 as a starting point the largest softdevice I can upgrade is 98K (4K MBR + 94K SD) in SD+BL mode.

How much can I expect S110 to grow in the next few major versions?

Does nordic have a roadmap for the next few major versions of S110. The one feature I'm really waiting for is support for larger MTU sizes via fragmentation and reassembly.

I'm getting fairly close to needing to lock down the value of NRF_UICR->BOOTLOADERADDR. I don't want to make a decision now that will prevent me from using the next few major softdevice versions in the future.

[Asbjørn Sæbø]

Clem (and others),

you are right, for an upgrade of the SoftDevice to a new major version (or to a different SoftDevice) you should assume that a bootloader update is also needed. SoftDevice major revisions will typically (always, so far) be due to API changes. Those API changes may affect the parts of the SoftDevice used by the bootloader, in which case the bootloader must be updated at the same time.

The maximum SoftDevice size that can be updated is : (FLASH_SIZE - MBR_SIZE - 2BOOTLOADER_SIZE)/2 + MBR_SIZE. That is (numbers in kBs): (256 - 4 - 2BL_SIZE)/2 + 4 kB. (Other data stored in flash during the update will also subtract from this.)

DFU is an important feature to us, we believe it is of great value both to you (our customers) and to ourselves. And we are very aware of the limitation this imposes on the size of the SoftDevice. The bootloader delivered with the SDK is around 13 kB (reserves 16 kB, I believe). Using that bootloader, a SoftDevice of 114 kB would be the largest that could be updated.

As for the SoftDevice size, we are trying to strike a balance here. We are adding new functionality (many of these requests come from customers), and that adds to the code size. We do want to keep the code small, but there are costs associated with this. Effort spent on optimizing code size is effort not spent on feature development and maintenance. Optimized code may also be harder to maintain and more prone to bugs. So far, we think we have a balance between code size, memory size, feature set and feature development speed, bug fixes and maintenance cost that seems to serve our customers well. Customers have different needs, though, so if you have input to how we prioritize this, we appreciate your feedback and will take it into account. (Concrete feedback through technical support or sales is what we prefer.)

As for future plans, I will (at lest for now) refer you to official communication from our sales department. They should be able to give you the most up-to-date roadmap on planned products and versions. (Sorry for being vague here, but that is how responsibility is split.)

A concrete question: Since you have rolled your own bootloader (or at least are capable of modifiying it heavily) and also have an external flash available - would it be possible to use that external flash for temporary storage of new bootloader/SoftDevice?

With kind regards Asbjørn S. (SoftDevice project leader)

Update: (2015-03-16) I can say a bit more about our future plans. In the S110 verson 8.0.0, we have managed to add some often-requested features and we have also aligned the API with the S120. We are committed to maintain the S110 8.x series, with bugfix releases and possibly minor releases as required. Any such versions will have the same size as the version 8.0.0. But we do not currently have plans for new major versions of the S110 SoftDevice. That is, we have no plans for the S110 that will require a size change. (A size change will require a new major version, as it breaks backwards compatibility.) I hope this helps to address your concerns regarding update to future versions.

With kind regards Asbjørn S.

[Clem Taylor]

Yes, we rolled our own bootloader and are just using ble_dfu.c for protocol compatibility.

I have an external SPI flash on the device and I strongly considered using it for scratch space for the a firmware upgrade or storing a backup copy of the device firmware. The idea is the bootloader would not depend on the softdevice and just validate CRCs and copy data from the SPI flash to the onchip flash. If it was kept simple enough we wouldn't have any need to upgrade the bootloader. However, I ended up spending the effort to get a working BLE DFU bootloader. If I had it to do over I would have gone down this path.

Initially I reserved 32K for the bootloader which was a mistake, After a bit of a diet I got the bootloader down to 24K. I could easily make it a bit smaller, but I needed to leave some of the uart debug data in to make it easier for the application application side.