Change Bootloader start address

[Andre N]

I need to do a DFU via BLE but I do not have enough memory.
For the past few months I have been working on a custom bootloader that would use an external memory to do the DFU.
The problem is that the new bootloader is bigger than the previous one and requires me to change the allocated memory.

	Current Memory Layout	New Memory Layout
Bootloader Settings Page	0x3F000 to 0x40000	0x3F000 to 0x40000
MBR Params Page	0x3E000 to 0x3F000	0x3E000 to 0x3F000
Bootloader	0x38000 to 0x3E000	0x37000 to 0x3E000

I only have two options:

• Allocate only 0x500 for the settings page and params page so that they will fit between 0x3F000 and 0x40000.
• Move the bootloader start address

I know this is not recommended but I have no choice in this case.
I cant change the hardware, I already have tens of thousands of devices with the clients that can only be updated through BLE DFU.

As it was mentioned in another public ticket, for SoftDevice versions beyond 6.1, the bootloader start address is stored in the MBR.
I need to know how can I modify this address correctly.

For now i have disabled the memory flash protection of the MBR, in main.c, so that I can modify the value.
Then in nrf_bootloader_fw_activation.c, i modify that value right before the MBR is called to replace the bootloader by calling this function:

• nrf_nvmc_write_word(MBR_BOOTLOADER_ADDR, (uint32_t) 0x37000);

However, if I read the value stored in MBR_BOOTLOADER_ADDR, it is not necessarily the value I have written.
How can I change this value?

If this is actually impossible, can I reduce the allocated size for the params and settings pages? they only need  800 bytes each but they allocate 4096 each.

[Andre N]

Unfortunately that wouldn't work for me.

We use a mobile app to interact with the device and the DFU can only be done through BLE.
We need to keep it user friendly because our product is destined to the general public and not necessarily tech savvy users.

The SPI flash seems to be my best option but if I implement the SPI protocol, the bootloader grows in size.
And since i cant change the bootloader's start address, i cant use the SPI.
From what i have seen, the start address is stored both on the UICR and MBR. However the MBR will check if it knows the BL address and it will only check on UICR if he doesnt already have a BL address.

I am now trying to do as Turbo said and reduce the size of the BL by using size optimisation flags.
This allows me to have a new BL small enough to fit in the space i have.
But for some reason the CRC checks fail with this BL version, so i'll new to check why.

If anything else fails, i will try using incompatible BL/SD to see if it works.
It seems to me that the only difference between s112 and s113 is "LE Data Packet Length Extension" (that i will need to have better speeds on my application, not my BL) and "L2CAP with LE Credit-based Flow Control".

If my bootloader used s113 with Data Length Extension, it would probably not be compatible with s112.
But hopefully in my case i wont have an issue

[Hieu]

Hi Andre N,

My apology for the late response.

I think that whether the DFU solution is complex or not, it is always a good idea to keep your mobile application all its inner working in a black box, opaque to the end users. 

As for using incompatible BL and SD, our stance remain that we strongly recommend against it. Please be aware that complex and hard-to-find problems might occur, such as the incompatibility causing issues only after significant runtime.

I think you can test this right away by flashing individually the S113 with MBR and your S112-compatible bootloader on an erased device.

As for the Data Length Extension feature, the bootloader likely has that enabled by default, but I figure you can update the bootloader to a version that does not use that feature first? This is not to suggest you pursue the mismatch SD-BL idea, but merely technical discussion.

Please remember that we are discussing updating the bootloader on-field devices, so you need to weigh the risks of those devices bricking.

Hieu