This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SDK12.3. Secure Bootloader : UART and ld config

Hi all

I'm working on a custom board using gcc and eclipse.

My primary problem is I'm fighting with the ld settings for the secure bootloader. I activated the RTT which led to a slightly larger HEX debug built.

   text	   data	    bss	    dec	    hex	filename
  30344	    144	   4824	  35312	   89f0	bootloader_nrf51_qaac_S130.out

according to this I changed the settings as follows:

MEMORY
{
  FLASH (rx) : ORIGIN = 0x37000, LENGTH = 0x8C00 // rounded to full page

  RAM (rwx) :  ORIGIN = 0x20003C00, LENGTH = 0x4380 // SD Mem - 32kb -NoINIT

  NOINIT (rwx) :  ORIGIN = 0x20007F80, LENGTH = 0x80 // NoInit

  /** Location of bootloader setting in at the last flash page. */
  BOOTLOADER_SETTINGS (rw) : ORIGIN = 0x0003FC00, LENGTH = 0x0400

  /** Location in UICR where bootloader start address is stored. */
  UICR_BOOTLOADER (r) : ORIGIN = 0x10001014, LENGTH = 0x04
}

Is my calculation correct? Further I'm using BSP_DEFINES_ONLY and custom_board.h which holds the LFCLKSRC definition...

What is also puzzling me is the hint in the comment above the FLASH(rx) definition: "BOOTLOADER_REGION_START found in dfu_types.h" there is neither the file nor the definition, I found it in nrf_bootloader_info.h and it is resolved as &__isr_vector. So there seems to be no need to set it via define as I understand this...

Something of the settings above is wrong, as the debugger is not stoping in the bootloader main...

The second question: Is it possible to backport the serial secure dfu from SDK v13? Anybody did or tried that yet?

  • Hi Martin,

    BOOTLOADER_REGION_START is replaced by BOOTLOADER_START_ADDR in Secure DFU.

    The .ld file was inherited from Legacy DFU (SDK v11 and earlier). The comment and some other configuration (such as the NOINIT sectioN) should be updated. We will try to fix this in next release of the SDK.

    I can see that you move the bootloader up a little bit. It's fine if you want to have more space to receive image and for application. But in case in the future we need to update the bootloader and make it larger size you may have an issue. It's better to have some buffer.

    Note that when you change the bootloader start address, you need to do a full erase of the chip , so that the UICR is erased properly.

    I don't see any problem back porting the serial DFU from SDK v13 back to SDK v12 or earlier.

  • Hi, I erased the chip a couple times. But still no luck in hitting the break point. The puzzling thing about it is, I see the NRF_LOG output printed in the RTT console...

  • :INFO:Inside main :INFO:In nrf_bootloader_init :INFO:In real nrf_dfu_init :INFO:running nrf_dfu_settings_init :INFO:Enter nrf_dfu_continue :INFO:Single: Invalid bank :INFO:Application sent bootloader request :INFO:In nrf_dfu_transports_init :INFO:num transports: 2 :INFO:vector table: 0x00035c00

    This is my init output, but the break point at main is not hit...

  • Okay, I found the root cause of all my problems:

    Inside the Makefile the CFLAG+= -flto was set, which caused the debug symbols to be discarded and caused the debugger to not find the symbols...

    Maybe this helps somebody too

Related