S110 v8.0.0 softdevice size and DFU update

RE: S110 v8.0.0 softdevice size and DFU update

Clem Taylor — Sat, 14 Mar 2015 23:55:16 GMT

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.

RE: S110 v8.0.0 softdevice size and DFU update

Asbjørn Sæbø — Fri, 13 Mar 2015 16:59:10 GMT

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.

RE: S110 v8.0.0 softdevice size and DFU update

Hung Bui — Fri, 13 Mar 2015 10:09:13 GMT

@Marcel: I guess the suggestion was from the case with EDIV and DIV. I believe the issue you were facing was something similar to this bug #2 in SDK v6.0 that we fixed in SDK v6.1 and above. If you OK with that then S110 v7.1 is still a good option. I have reported your comment to our R&D for consideration and improvement.

@Clem: I have reported your comment to our R&D for consideration and improvement. The information I got from R&D is that v8.0 could be the final version of S110. There could be some minor revision releases for bug fix, but it will be pretty much stable as it is at v8.0.

RE: S110 v8.0.0 softdevice size and DFU update

Clem Taylor — Wed, 11 Mar 2015 18:50:17 GMT

My reason for asking this question was to find out how much of a diet I need to give my bootloader if I want to be able to support the next few major releases. I sent an email off to my sales rep.

Part of the reason my bootloader is larger is because it has quite a bit of additional functionality (RSA/SHA1 signed and AES encrypted firmware, OLED display support for user feedback, upgrade of an external SPI flash, no performance problems with 7.5ms connection interval, etc.)

I know need to put my bootloader on a diet, but many of the big size offenders are the SDK code. For example SWI0_IRQHandler() from app_timer is 1000 bytes. For comparison this is larger then the libc printf() I'm using. It is also larger then my rsa_decrypt+sha1+crc-32 code combined,

RE: S110 v8.0.0 softdevice size and DFU update

Marcel Mulder — Wed, 11 Mar 2015 16:16:35 GMT

Funny, a colleague of you just ask me if I could upgrade to s110 v8 for another problem. I do not know the code of the softdevice off course but it will be similar to what I see in the SDK. What I notice is that a lot is checked runtime. This is a huge part of the code. Ok, some parameters should be checked but most of them can be checked with static asserts or only in a debug mode. And sometimes it beter to just crash when something is not ok. You see it directly and the bug can be fixed. Almost all code is static. You (as far as I known) don't use the heap. Most of us don't I think. So instance should just exist. If not a hard fault is ok. In my (humble) opinion most of the Nordic code is quite "big". I move more and more away from the SDK because there is to much overhead in there. It hard to point this out in this piece of text. I have only 21 characters left ;-)

RE: S110 v8.0.0 softdevice size and DFU update

Hung Bui — Wed, 11 Mar 2015 15:05:30 GMT

@Marcel: Thanks for your suggestion. If you can send me here or via private support portal case on your ideas it would be great. Regarding your concern for the side, I guess you can think of moving back to S110 v7.1 which occupies 8kB less. So you will have 20kB left for your application. There are some bug fixes and new features on S110 v8.0 but it's not a very big deal.

RE: S110 v8.0.0 softdevice size and DFU update

Marcel Mulder — Wed, 11 Mar 2015 06:45:54 GMT

I am concerned also. We targeted for the 128 kB Flash devices because of the price. We can't afford 256 kB devices. Having only 128 kB of flash minus the SD of 96 kB leaves 32 kB. Lowering it with 16 kB for the bootloader and an additional 4 kB for storing data I have only 12 kB left. There is not much what I can do with this. Even the bootloader is bigger! The 128 kB devices are almost useless except for small dedicated solutions which don't need (or able to) update and only needs S110. Other softdevices are not possible at all for real applications. May be Nordic can think about doing a statement about future sizes or make some effort in downsizing (I will have some tips ;-) the SD.

RE: S110 v8.0.0 softdevice size and DFU update

Hung Bui — Tue, 10 Mar 2015 14:10:02 GMT

@Clem: It's hard to tell about the future product. You can contact our sale staff in your area for more information. Please pm me your location I can send you the contact.

But what you can do for now is to reduce the size of the bootloader. Have you used any optimization when compiling the code ? Our bootloader only takes about 14KB of code.