SDK11 serial DFU to s132v4 from s132v2

Recently I have been working with the serial bootloader from SDK 11. I can upload a softdevice, and supporting application using this bootloader without issue, as long as it’s the same softdevice version. In the case of SDK 11, that would be s132v2.

Now for the problem:

I have a separate application built against SDK 13, using s132v4. It blinks an LED and exposes a BLE service, nothing fancy. My thought process was that I would use this application as input to the bootloader described above, updating the softdevice from s132v2 to s132v4, and loading my test blinky application.

This however does not work. It happily accepts the new softdevice, resets the device, but fails on softdevice_enable, specifically: NRF_ERR_NO_MEM, regardless of linker adjustments in .icf. There’s plenty of posts which describe how to solve this issue, but in my case app_ram_base matches and returns with:

sd_ble_enable() returned unexpected value: 0x04

After a bit of searching I found this, which describes a fix in dual_bank.c, but it didn’t seem to have an impact, and I think its downstream of my immediate issue.

Below is my linker file and a snippet from dfu_types.h. I also verified UICR as a test.

define symbol __ICFEDIT_intvec_start__ = 0x70000;
/*-Memory Regions-*/
define symbol __ICFEDIT_region_ROM_start__   = 0x70000;
define symbol __ICFEDIT_region_ROM_end__     = 0x7dfff;
define symbol __ICFEDIT_region_RAM_start__   = 0x20002c00;
define symbol __ICFEDIT_region_RAM_end__     = 0x2000ff7f;
export symbol __ICFEDIT_region_RAM_start__;
export symbol __ICFEDIT_region_RAM_end__;
/*-Sizes-*/
define symbol __ICFEDIT_size_cstack__   = 0x800;
define symbol __ICFEDIT_size_heap__     = 0x200;
/**** End of ICF editor section. ###ICF###*/

dfu_types.h:

#elif NRF52     
        
#define BOOTLOADER_REGION_START             0x00070000                  /**< This field should correspond to start address of the bootloader, found in UICR.RESERVED, 0x10001014, register. This value is used for sanity check, so the bootloader will fail immediately if this value differs from runtime value. The value is used to determine max application size for updating. */
#define BOOTLOADER_SETTINGS_ADDRESS         0x0007F000                  /**< The field specifies the page location of the bootloader settings address. */
#define BOOTLOADER_MBR_PARAMS_PAGE_ADDRESS  0x0007E000                  /**< The field specifies the page location of the mbr params page address. */
        
#define CODE_PAGE_SIZE                      0x1000                      /**< Size of a flash codepage. Used for size of the reserved flash space in the bootloader region. Will be runtime checked against NRF_UICR->CODEPAGESIZE to ensure the region is correct. */

#else

Verify UICR:

$ nrfjprog --memrd 0x10001014 --n 4
0x10001014: 00070000 

In the end, my goal is to use the existing bootloader from SDK 11, and upload an application which is built against SDK 13, s132v4.

The use case above can be reproduced by running the dfu example from SDK 11 and using nRFGoStudio's bootloader utility to generate a zip of s132v4 from SDK 13. I am 99 percent sure the issue is something I am doing wrong on my end, but can't seem to get around it. Any direction would be greatly appreciated.

Steps:

1.) Flash s132v2 from nRFGoStudio
2.) Run dfu example and put into DFU mode
3.) Go into nRFGoStudio's bootloader util and flash s132v4 softdevice only as zip
4.) Results in NRF_ERR_NO_MEM. Tried with multiple linker configurations. As well as enabling/disabling softdevice protection in nRFGoStudio for the initial softdevice.

As a side note, I should also mention that I would like to stick with the basic bootloader from SDK11, not the secure bootloader from SDK13.

Update:

A few more details. This happens while updating from S132 v2.x.x to S132 v4.x.x. I have provided screenshots below:

Prior to running the bootloader example:

image description

Initial bootloader in DFU mode waiting for update:

image description

After update, nRFGoStudio reports back "Device Programmed", program then resets and fails with NRF_ERR_NO_MEM:

image description

  • When you say that softdevice_enable() returns error code 0x04, is this in the bootloader or the application?

  • Hi @Bjørn Spockeli, this is in the bootloader, specifically via ble_stack_init within the dfu_dual_bank_serial_s132 example. The error happens at step 3. The bootloader starts and enters DFU mode, at this point I switch over to nRFGoStudio and upload s132v4 with its utility, the bootloader then gives NRF_ERR_NO_MEM.

  • So this is after you have updated from from S132 v2.x.x to S132 v4.x.x? Also is the bootloader present on the device after the update built against SDK v11.0.0 and the S132 v2.x.x ?

  • Hi @Bjørn, I have update the original with the details you requested. One thing I noticed right away was that the application address is different in the two screenshots, I guess that makes sense though as the s132v4(124kB) > s132v2(112kB).

  • Yes, that is because the S132 v4.x.x SoftDevice is larger than the S132 v2.x.x, which means that application start address must be shifted upwards. However, you did not answer my question: Is the bootloader present on the device after the update of the SD and Application still based on SDK v11.0.0 and S132 v2.0.0? If that is the case then you have a bootloader that is incompatible with the S132 v4.0.0 SoftDevice and that is why your're getting an error. You will have to compile the SDK v11.0.0 bootloader against the S132 v4.0.0 headers and update the bootloader, application and SoftDevice.