Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

nrf52832_xxAB secure bootloader

Hello everyone,

Because of problem with availability we were forced to change our ready-for-production project from nRF52832_xxAA to nRF52832_xxAB which has 2x less FLASH and RAM memory.
From application point of view it wasn't a problem - we easily adjusted memory regions in linker configuration but we are struggling with a bootloader.
We use the secure bootloader from SDK15.3.0/examples/dfu/secure_bootloader/pca10040_ble/armgcc with very minor changes.

First of all, we have found this thread (which summarize changes necessary to support xxAB version by the bootloader library) and made proper patch.
Next, we changed in Makefile all references from xxAA to xxAB.
And finally we went to the linker file which is the actual problem.

Original linker file (for nRF52832_xxAA) looks as following:

MEMORY
{
  FLASH (rx) : ORIGIN = 0x78000, LENGTH = 0x6000
  RAM (rwx) :  ORIGIN = 0x200057b8, LENGTH = 0xa848
  uicr_bootloader_start_address (r) : ORIGIN = 0x00000FF8, LENGTH = 0x4
  uicr_mbr_params_page (r) : ORIGIN = 0x00000FFC, LENGTH = 0x4
  mbr_params_page (r) : ORIGIN = 0x0007E000, LENGTH = 0x1000
  bootloader_settings_page (r) : ORIGIN = 0x0007F000, LENGTH = 0x1000
}

Flash memory can be easily adjusted, but is seems that RAM memory used originally by the bootloader is bigger then nRF52832_xxAB has (0xa848 = 42116B > 32KB).

So, the question is: Does bootloader really needs so much RAM or can it be safety reduced? Can you recommend some settings?

I played a bit with RAM regions but without luck, I wasn't able to make it running properly.
If I reduce RAM dedicated for SoftDevice (by reducing ORIGIN number) then bootloader is not able to start. On the other hand , if I reduce RAM dedicated for bootloader (by reducing LENGTH number and STACK_SIZE in Makefile) then bootloader starts but every DFU try fails.

This is my current settings but it's not working:

MEMORY
{
  FLASH (rx) : ORIGIN = 0x38000, LENGTH = 0x6000
  RAM (rwx)  : ORIGIN = 0x20005768, LENGTH = 0x2848
  uicr_bootloader_start_address (r) : ORIGIN = 0x10001014, LENGTH = 0x4
  uicr_mbr_params_page (r) : ORIGIN = 0x10001018, LENGTH = 0x4
  mbr_params_page (r) : ORIGIN = 0x0003E000, LENGTH = 0x1000
  bootloader_settings_page (r) : ORIGIN = 0x0003F000, LENGTH = 0x1000
}

Parents
  • I have found the issue, the problem was that my Makefile had the following definitions:

    ...
    CFLAGS += -DNRF52
    CFLAGS += -DNRF52832_XXAB
    ...
    
    ...
    ASMFLAGS += -DNRF52
    ASMFLAGS += -DNRF52832_XXAB
    ...

    But it came out that nRF5_SDK_15.3.0_59ac345/modules/nrfx/mdk/nrf.h has the following statement:

    /* Redefine "old" too-generic name NRF52 to NRF52832_XXAA to keep backwards compatibility. */
    #if defined (NRF52)
        #ifndef NRF52832_XXAA
            #define NRF52832_XXAA
        #endif
    #endif

    which caused that patch for bootloader didn't work and still took definitions for nRF52832_XXAA processor.

    Removing `NRF52` definition from CFLAGS and ASMFLAGS solved the problem.

Reply
  • I have found the issue, the problem was that my Makefile had the following definitions:

    ...
    CFLAGS += -DNRF52
    CFLAGS += -DNRF52832_XXAB
    ...
    
    ...
    ASMFLAGS += -DNRF52
    ASMFLAGS += -DNRF52832_XXAB
    ...

    But it came out that nRF5_SDK_15.3.0_59ac345/modules/nrfx/mdk/nrf.h has the following statement:

    /* Redefine "old" too-generic name NRF52 to NRF52832_XXAA to keep backwards compatibility. */
    #if defined (NRF52)
        #ifndef NRF52832_XXAA
            #define NRF52832_XXAA
        #endif
    #endif

    which caused that patch for bootloader didn't work and still took definitions for nRF52832_XXAA processor.

    Removing `NRF52` definition from CFLAGS and ASMFLAGS solved the problem.

Children
No Data
Related