Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

Bootloader with ISR-Vector at the end?

We are developing part of an application for products that are supposed to have 10+ years of service life with updates over the whole lifetime. We want to have a flash memory layout that supports this in a good way.

The softdevice has to be installed at 0x1000. Then we have our application. We won't install a new Softdevice without installing a new application so both can grow in size without a problem.

We also have a small bootloader near the end of the flash memory that decrypts, verifies and installs upgrades. It can also upgrade itself by calling the MBR with the SD_MBR_COMMAND_COPY_BL command.

The bootloader should do more things in the future and then it will then need more flash memory. We don't know how much and we don't want to reserve more than needed.

We tried to solve this by putting the ISR vector at the end of the bootloader's reserved memory, then newer versions could grow downwards as needed. This doesn't work though as we can't upgrade it with SD_MBR_COMMAND_COPY_BL as it only takes source and length parameters. Is this possible to solve in some other way without having to use a second stage bootloader?

Parents
  • Hello,

    I don't think this is possible using the nRF5 SDK bootloader, unfortunately. The nRF Connect SDK bootloader is built a bit different, so perhaps that can work for your usecase.

    If you want to go with the nRF5 SDK, you can do everything you mentioned - except changing the bootloader's start address - via DFU. So as far as I know, you would need to set aside enough memory for future bootloaders. You would have to make an estimate, and set that to the bootloader size. What kind of changes to the bootloader do you imagine you would want to add?

    Best regards,

    Edvin

  • Hi!

    I expect we want to add support for uploading a new firmware to the device via bluetooth, USB or UART directly from the bootloader. Currently that is only handled in the application's code.

    I think we can add support for that via a second stage bootloader that a future bootloader will install/upgrade, so we don't really need to reserve a lot of extra flash right now except enough room to add code to install a second stage bootloader.

    BR,
    Sebastian

Reply
  • Hi!

    I expect we want to add support for uploading a new firmware to the device via bluetooth, USB or UART directly from the bootloader. Currently that is only handled in the application's code.

    I think we can add support for that via a second stage bootloader that a future bootloader will install/upgrade, so we don't really need to reserve a lot of extra flash right now except enough room to add code to install a second stage bootloader.

    BR,
    Sebastian

Children
No Data
Related