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

S110 v8.0.0 softdevice size and DFU update

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.

Parents Reply Children
  • 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.

  • @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.

  • 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 ;-)

  • 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,

  • @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.

Related