RE: Can we get a size-constrained BLE transport DFU bootloader?

tesc — Tue, 07 May 2019 09:31:14 GMT

Hi,

Thank you for valuable feedback! It is always appreciated.

I have sent your suggestions and rationales through our internal channels, and it is taken into account for further development of our solutions.

Regards,
Terje

RE: Can we get a size-constrained BLE transport DFU bootloader?

Anne van Rossum — Thu, 02 May 2019 10:43:20 GMT

It's a sad choice. In general I would like to address the tendency of the code becoming bigger and bigger. With the bootloader it's in particular obvious. Is there a team at Nordic that has size restrictions as their main goal? I mean newlib was first also meant to be used on embedded systems. However, that doesn't mean that something like newlib-nano is something to strive for. If you have a group of Nordic engineers that do not focus on the newest chipsets, but keeping the code size in check, I think you'll have a very good impact on the ecosystem:

Older devices will have much longer lifetimes because software updates can still happen;
There have to be more choices for the user to pick which parts they want from the bootloader/softdevice. This means that the code becomes more modular. That you cannot remove the security parts from the bootloader testifies to the fact that modularity of the code has suffered.
If size becomes an issue again, for example, for chipsets that you want to use in energy-harvesting context and that have even a lower energy footprint than what you have now, you don't need to create new software from scratch. Powering up RAM costs energy.
If devices have longer lifetimes they do not need to be replaced as soon. This is good from an environmental perspective, plastic, polution, production waste, etc.
If devices have longer lifetimes where they indeed can receive modern software updates over the air, they stay longer functionally relevant. This means that products with Nordic insight will be considered as higher quality and more modern than those of other manufacturers.
You will make the developers in your ecosystem happier if they have more control over the size of the code blobs generated by Nordic.
You will make managers happier if they have more control over these aspects. Nobody wants to run into non-compatibility issues due to their choice of chip manufacturer. Those sizes might grow again and again, especially if the issue is not recognized as an important design constraint internally at Nordic.

If you wouldn't mind to spend some time with a team on this, it would be of great benefit to the community / your customers / the customers of your customers. Thanks for listening!

RE: Can we get a size-constrained BLE transport DFU bootloader?

tesc — Tue, 30 Apr 2019 12:29:34 GMT

Hi,

Have you had a look at this answer on how to update from legacy bootloader to secure bootloader? It is possible to erase and rewrite the UICR registers on the nRF52, which means you can increase bootloader size if you can tolerate the risk involved.

If the above is not an option then maybe porting the legacy bootloader might be?

Regards,
Terje

RE: Can we get a size-constrained BLE transport DFU bootloader?

Andy — Tue, 30 Apr 2019 10:18:55 GMT

Pff, I had this same concern some time ago. Sorry to hear that you actually ended up in the no-compatibility spectrum. This is what Nordic had to say about this when I asked about the size constraints of the bootloader, in case you're interested.