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

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

Related