• State Not Answered
  • Replies 4 replies
  • Subscribers 86 subscribers
  • Views 1198 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 228299
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

Anne van Rossum

We're having thousands of products in the field that require an update to SDK15. We provisioned the bootloader with ample space (0x5000), which amounts to 20480 bytes. The bootloader used to be 15624 bytes. However, now, with all kind of feature creep the bootloader is increased to 23464 bytes. Due to the fact that you cannot change the bootloader address with DFU, we're out in the cold.

Can you provide a bare-bones no-thrills minimized bootloader with DFU over BLE that is compatible with your latest SDK? Forget all the cool stuff you want to put in it. Now, you're artificially limiting the lifetime of our products. The alternative to implement our own bootloader is no fun and I can't imagine that others won't face the same problems.

Observation: the size of the bootloader is not taken as serious design limitation

Wish: provide a bare-bones BLE transport DFU bootloader - like you used to have - which is compatible with your latest SDK.

A configuration example to the same effect would be great as well. Disable all encryption backends should be an option.

Parents
  • 0

    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

  • 0 in reply to tesc

    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:

    1. Older devices will have much longer lifetimes because software updates can still happen;
    2. 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.
    3. 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.
    4. 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.
    5. 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.
    6. You will make the developers in your ecosystem happier if they have more control over the size of the code blobs generated by Nordic.
    7. 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!

Reply
  • 0 in reply to tesc

    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:

    1. Older devices will have much longer lifetimes because software updates can still happen;
    2. 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.
    3. 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.
    4. 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.
    5. 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.
    6. You will make the developers in your ecosystem happier if they have more control over the size of the code blobs generated by Nordic.
    7. 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!

Children
Related
Terms of service