0

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

Wojtek Węclewski gravatar image

asked 2017-07-17 17:24:52 +0200

updated 2017-07-18 10:24:40 +0200

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

edit retag flag offensive close delete report spam

1 answer

Sort by » oldest newest most voted
0
bjorn-spockeli gravatar image

answered 2017-07-18 16:13:18 +0200

updated 2017-07-18 16:16:29 +0200

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?

edit flag offensive delete publish link more

Comments

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.

Wojtek ( 2017-07-18 16:58:54 +0200 )editconvert to answer

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer. Do not ask a new question or reply to an answer here.

[hide preview]

Question Tools

Stats

Asked: 2017-07-17 17:24:52 +0200

Seen: 61 times

Last updated: Jul 18