S332 + Bootloader_secure memory map and linker config

[Allen Foster]

Hi, I have some questions about the memory map, ram usuage and linker config for the secure bootloader when used with the S332 (4.05 sd_req 0x94) softdevice.

I have tried to get DFU to work with the default linker settings from SDK 13.1, these are

  FLASH (rx) : ORIGIN = 0x78000, LENGTH = 0x6000
  RAM (rwx) :  ORIGIN = 0x20002060, LENGTH = 0xDA70

However although my application would start when merged with the appropriate bootloader settings and flashed to the SoC, it would not perform a dfu update successfully.

If I change the bootloader linker settings to those from the Thingy FW secure bootloader implementation then it does work. These are as follows.

  FLASH (rx) : ORIGIN = 0x75000, LENGTH = 0x9000
  RAM (rwx) :  ORIGIN = 0x20002C00, LENGTH = 0x5380

I would like to understand why the Thingy FW bootloader linker settings work and why? Why was it necessary for the Thingy FW bootloader mem map to be changed and why do I need the same settings for my S332 based project. Are there any documents apart from Hung Bui's excellent guide?

Other background info about the rest of my application

S332 based application - using ANT_s332_nrf52_4.0.5.hex

My application size:

Preparing: app_nrf52832_xxaa_s332.bin
Preparing: app_nrf52832_xxaa_s332.hex

   text    data     bss     dec     hex filename
  57836     692    4244   62772    f534 _build/app_nrf52832_xxaa_s332.out

Linker config for my app

  FLASH (rx) : ORIGIN = 0x29000, LENGTH = 0x57000
  RAM (rwx) :  ORIGIN = 0x20004AD8, LENGTH = 0xB528

As I said, although I have DFU working successfully using the ThingFW secure bootloader linker settings I want to understand why the change was necessary in case I am missing some key point which could have other repercussions for the rest of the system.

Thanks for your help

-Allen

[Allen Foster]

Thanks for the reply Toyman,

Yes, I obviously changed the S132 defines to S332 in my bootloader build. Interesting to know it works 'out of the box' for SDK14 + S332.

I am curious why the linker config in the Thingy FW (using SDK 13.1) is different than the secure bootloader example inf the SDK 13.1 examples. As I said I need to use the ThingyFW bootloader config and want to understand why that is the case and any repercussions for the rest of my design.

[Bjørn Kvaale]

I believe the Thingy FW is based on SDK 13, not 13.1. Have you tried with the linker settings from sdk 13?

[Allen Foster]

Hi Bjorn,

The SDK 13 secure DFU example linker config is the same for SDK 13.1 for the RAM but different for FLASH.

SDK 13 secure DFU linker config:

  FLASH (rx) : ORIGIN = 0x78000, LENGTH = 0x6000
  RAM (rwx) :  ORIGIN = 0x20002C00, LENGTH = 0x5380

SDK 13.1 secure DFU linker config:

  FLASH (rx) : ORIGIN = 0x78000, LENGTH = 0x6000
  RAM (rwx) :  ORIGIN = 0x20002060, LENGTH = 0xDA70

ThingyFW (SDK13) bootloader linker config:

  FLASH (rx) : ORIGIN = 0x75000, LENGTH = 0x9000
  RAM (rwx) :  ORIGIN = 0x20002C00, LENGTH = 0x5380

In my S332 based application (SDK13.1) if I use the SDK 13.1 booloader linker settings above then the boatloader does not perform BLE DFU successfully but resets. If I use the ThingyFW bootloader linker settings it does work.

I want to understand why the ThingyFW uses different linker config that the secure DFU example in SDK13.

I hope that makes sense

[Bjørn Kvaale]

Could you try using the original settings from the sdk 13.1 bootloader & debugging the bootloader when doing the dfu? It might be that this function inside bootloader_start() leads to the error you mention: 

sd_softdevice_vector_table_base_set(NRF_UICR->NRFFW[0]);

It might be that the RAM origin address is wrong in the sdk 13.1 bootloader linker settings.

You can set a breakpoint at this function to see if an error is asserted. If there is no assert, you can let the bootloader restart the device & once you get into the application, it might be that the sd_ble_enable() function inside your application will ask you to adjust the linker settings. If it does, adjust the linker settings like told & hopefully everything should work like it should.

There should not be any other repercussions for the rest of your design because of the linker config error.

[Allen Foster]

I am using gcc to compile and a gdb server based debug arrangement. I tried to build the secure bootloader with compiler option -ggdb but I get the following error at linker time.

../../../../sdk_components/libraries/bootloader/nrf_bootloader_app_start_asm.c: In function 'nrf_bootloader_app_start_impl':
../../../../sdk_components/libraries/bootloader/nrf_bootloader_app_start_asm.c:129:1: error: r7 cannot be used in asm here
 }
 ^
lto-wrapper: /home/fostera/Tools/gcc-arm-none-eabi-4_9-2015q3/bin/arm-none-eabi-gcc returned 1 exit status
/home/fostera/Tools/gcc-arm-none-eabi-4_9-2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
make: *** [_build/ace_bootloader_nrf52832_s332.out] Error 1

Is there a known solution for this before I spend some time trying to find one myself?

Thanks again,

Allen

[Bjørn Kvaale]

Have you made any changes to the nrf_bootloader_app_start_asm.c file? Does the secure bootloader compile properly in Keil or Segger Embedded Studio? Have you tried this solution here?