• State Not Answered
  • Replies 2 replies
  • Subscribers 67 subscribers
  • Views 0 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 336726
Options

BLE 5.1 on small devices with BLE Bootloader

H.Marske

Hi,

We are currently developing a BLE device (HW and SW) using the NRF52811.

As we want to be able to update the device via FOTA we need to have the Bootloader to have the BLE-Stack.

We now have the BLE-Stack twice in our Program so it exceeds the maximum flash size.

We dont really want to switch the SoC´s as we want the DirectionFinding Feature and the next device capable is the nrf52833

 wich is quite a bit more expensive.

Is there any way to compress the Bootloader or maybe use the same BLE-Stack for both Application as well as bootloader?

Is there any way to compress the Bootloader to only have the BLE-DFU capabilitites?

Kind regards

H.Marske

Parents
  • 0

    Following on from Hieu's comments, another option is to accept a fixed Bootloader and SoftDevice and only update the application by using the application to download a new version of itself, unless there is insufficient room for 2 versions of the application (without softdevice) in flash memory. In that latter case the Bootloader could use the single Softdevice API directly to download a new application on top of the outdated application by restarting itself in Bootloader-with-SD mode, though I have not seen this done anywhere. The Bootloader would be compiled like an application with the softdevice included as the softdevice would use the exact same memory addresses as the real application. The OTA update would have to just overwrite the application code which is easy enough to separate from the application's own identical copy of the softdevice. The softdevice has no dependence on whether the Bootloader is in charge or the application is in charge if the vectors are managed by the Bootloader; the softdevice vector hooks to the Bootloader vector table which chooses whether in Bootloader or application mode, in the latter case forwarding vectors. ie it would be simpler to always have the "application" vector table be in the Bootloader; now the softdevice only talks to Bootloader vectors, which in turn can forward to the real application vectors in vector table in the application.

    Immediately following the vector table location at the start of the both the application and Bootloader functions and variables that have to be accessed by the other via "vector" pointers when the actual location in the application changes from build to build allows more space savings when both Bootloader and application would otherwise have duplicated code and indeed allows for patch fixes for the Bootloader.

Reply
  • 0

    Following on from Hieu's comments, another option is to accept a fixed Bootloader and SoftDevice and only update the application by using the application to download a new version of itself, unless there is insufficient room for 2 versions of the application (without softdevice) in flash memory. In that latter case the Bootloader could use the single Softdevice API directly to download a new application on top of the outdated application by restarting itself in Bootloader-with-SD mode, though I have not seen this done anywhere. The Bootloader would be compiled like an application with the softdevice included as the softdevice would use the exact same memory addresses as the real application. The OTA update would have to just overwrite the application code which is easy enough to separate from the application's own identical copy of the softdevice. The softdevice has no dependence on whether the Bootloader is in charge or the application is in charge if the vectors are managed by the Bootloader; the softdevice vector hooks to the Bootloader vector table which chooses whether in Bootloader or application mode, in the latter case forwarding vectors. ie it would be simpler to always have the "application" vector table be in the Bootloader; now the softdevice only talks to Bootloader vectors, which in turn can forward to the real application vectors in vector table in the application.

    Immediately following the vector table location at the start of the both the application and Bootloader functions and variables that have to be accessed by the other via "vector" pointers when the actual location in the application changes from build to build allows more space savings when both Bootloader and application would otherwise have duplicated code and indeed allows for patch fixes for the Bootloader.

Children
No Data
Related