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

Changing SD (s110->s130) and wrong memory organization

Hello,

I'd like to upgrade nrf51822 QFAC custom board firmware via DFU and change SoftDevice from s110 to s130. Because of larger (than s110) size of s130 I haven't enough space for my application with current FLASH memory organization.

Current FLASH memory organization:

  • s110:       0x00000 (size: 0x17000)
  • application:   0x17000 (size: 0x19000)
  • dfu:         0x30000 (size: 0x08000)
  • bootloader:   0x3D000 (size: 0x03000)

Separate DFU and bootloader is misconception and it'll be wonderful to use BLE Secure DFU Bootloader from SDK example, but I've read this Relocating the bootloader and this Relocating Bootloader by DFU.

My questions:

  1. Is there a way to relocate bootloader via DFU anyway (there are thousands of such devices over the world and it's impossible to update them using programmer)?
  2. Maybe there is a way to "shrink" BLE Secure DFU Bootloader so it'll fit 0x03000 bytes (maybe without "secure" it'll fit)?
  3. Could Nordic develop custom SoftDevice with bootloader start address given not from UICR.BOOTLOADERADDR?
  4. Any sugestions?

Regards, Wojtek

Parents
  • Hi Wojtek,

    Q1: As I stated in Relocating the bootloader

    It is not possible to change the bootloader address written to UICR.BOOTLOADERADDR from running code. The only way to relocate the bootloader is to erase the device and then flash the bootloader.

    This is because it is not possible to erase the UICR registers of the nRF51 without erasing the entire chip.

    Q2: The Secure bootloader has been shrunk in size as much as possible and I would not recommend trying to reduce the size by removing

    Q3: No, it is actually the MBR, not the SoftDevice, that reads the UICR.BOOTLOADERADDR register and then branches to the bootloader vector table at that specific address. The MBR makes it possible to safely perform Bootloader updates since the the bootloader cannot itself. Like the bootloader, the MBR cannot update itself, therefore we've made the MBR backwards compatible with all our SoftDevices so that we never need to updated it after it has been initially flashed to the device.

    Q4: You simply won't be able to fit the Secure Bootloader within 0x3000 bytes. I also think that reducing the Legacy bootloader from SDK v11.0.0 by 3kB(0xC00) is also not going to be possible.

    However, I do not quite understand the memory layout you posted in your question. Have you created your own custom bootloader that separates the actual DFU process from the process of swapping the old firmware with the new? If so what was the reason for this modification?

  • That is old code, written by developers I didn't know personally, and I can only imagine why they done that this way.

    Well, this isn't good news but thanks for reply.

Reply Children
No Data
Related