nRF51822 over the air bootloader with gcc

Question

For my current project, I need to compile the »over the air bootloader« with gcc (because our buildserver runs on linux, developers using Mac … no Windows and no Keil so far). 
 But unfortunaly, the bootloader example from the sdk (5.1) examples won't compile with gcc. It's missing gcc makefile and even there are at least 2 Keil specific files in the project (arm_startup_nrf51.s and bootloader_util_arm.c). 
 Could you provide support to help me on this topic? 
 I'd also checked:- devzone.nordicsemi.com/index.php/nrf51822-bootloader-with-gcc 
 
 devzone.nordicsemi.com/index.php/the-bootloader-for-nrf51822 
 github.com/hlnd/nrf51-pure-gcc-setup 
 github.com/hlnd/nrf51-ble-bootloader 
but don't want to waste time with tinkering and try around various different approaches.
I hope there was a solid and straight forward way.

Joe Merten · Accepted Answer

Ok, after staying without any response for a week, I do it myself. 
 My development & testing environment 
 
 Linux Host (Kubuntu 12.04, 32 Bit) 
 Nordic nRF51 Sdk version 5.1.0 
 SoftDevice S110 version 6.0.0 
 nRFgo starterkit (nRF6700 motherboard) 
 nRFgo nRF51822 cpu board (PCA10004, Rev. 2.2.0) 
 Segger JLink lite 
 Arm gcc 4.8 ( gcc-arm-none-eabi-4_8-2013q4-20131204 ) 
 Also using Ole Morten's pure-gcc setup 
 For testing ota update, I use »nRF Mcp« and »nRF Toolkit« on an Android 4.3 tablet (Samsung Note SM-P605) and also »nRF Loader« on an iPhone 4s
This refers to the bootloader example from the Nordic Sdk.
Makefiles and all other changes are in the attached archive.
Within my tests using the pure-gcc setup, the bootloader works well. But using the Sdk's gcc setup, I'll often got a hardfault. → Update: After modifying the assemblercode in bootloader_util (added .ALIGN) it seems also to work. 
 
 Build using Ole Morten's pure-gcc setup 
For pure-gcc, just enter into directory pure-gcc and call »make« or »make flash«.
You may have to adjust the path settings for your gcc installation et cetera:- SDK_PATH 
 
 TEMPLATE_PATH 
 TOOLCHAIN_PATH
You can either edit pure-gcc/Makefile or pass them when calling make (e.g. »make SDK_PATH=…«). 
 
 Build using the Sdk's gcc setup 
 For using the Sdk's original gcc setup, you have to set the make variables:- SDK_PATH 
 
 GNU_INSTALL_ROOT 
 GNU_VERSION
Because of the Sdk lack regarding linux host support (no Makefile.posix) and the unflattering definition of that variable in Makefile.windows (it's not defined using ?=), GNU_INSTALL_ROOT could not be set in the project's Makefile but must e.g. passed as a parameter when calling make (or you're going to modify the Sdk's makefiles), e.g.:
 $ make release GNU_INSTALL_ROOT=… 
 
 Linkerscripts 
 When compiling with armcc, the bootloader seems to need something about 14k flash (13k code and 1k for persistent data).
With gcc, we need more space for code (about 15k when using gcc 4.8; gcc 4.7 needs a bit more).
Within the linkerscripts, I'd set the flash size for the bootloader from 14k to 24k (but it can be reduced to 16k).
Take note, that the UICR must be correctly set up to match the bootloaders flash address, which is 3C800 for the 14k bootloader but 3A000 for the 24k sized: 
 J-Link>mem 10001014 4
10001014 = 00 A0 03 00

 
 The »gcc_nrf51_s110_bootloader.ld« ist for the »pure-gcc« setup and the »gcc_nrf51_s110_xxaa_bootloader.ld« is for the sdk gcc. Yep, the naming could be better and maybe both files could put into one. 
 In »dfu_types.h«, the bootloader's flash address must be adjusted to match the value in the linkerscript: 
 #define BOOTLOADER_REGION_START 0x0003A000

 
 bootloader_util 
 I'd made a bootloader_util_gcc.c as a substitute for bootloader_util_arm.c
But see also this post 
 Bootloader's persistent config in flash 
 The bootloader saves some persistent data into the most upper flash page (1k at address 3FC00) and uses 16 byte (from the 1k) for storing informations e.g. about the application. 
 J-Link>mem 3FC00 10
0003FC00= 01 00 00 00 32 43 00 00 FF 00 00 00 E4 3D 00 00

 
 The regarding data structure is found in »bootloader_types.h« and named »bootloader_settings_t«. There is a problem with the »enum bootloader_bank_code_t« because the size of this enum is 32 bit in armcc but 16 bit in gcc. I'd modified that slightly so that it is also 32 bit for gcc. 
 Bootloader's Codesize 
 Using Ole Morten's pure-gcc setup: 
 arm-none-eabi-size _build/Blebl_s110.elf
 text data bss dec hex filename
 14248 1108 2096 17452 442c _build/Blebl_s110.elf
→ 15.356 byte flash size (plus 1k persistent config)

 
 Using the Sdk's gcc setup: 
 arm-none-eabi-size _build/BleblSdk.out
 text data bss dec hex filename
 14200 1108 2096 17404 43fc _build/BleblSdk.out
→ 15.308 byte flash size (plus 1k persistent config)

 
 Edit:
Using Sdk 5.2.0, the codesize has grown a bit (about 604 byte). 
 arm-none-eabi-size _build/Blebl_s110.elf
 text data bss dec hex filename
 14880 1100 2076 18056 4688 _build/Blebl_s110.elf
→ 15.960 byte flash size (plus 1k persistent config)

 
 But when using NewLib-nano (by specifying »LDFLAGS = --specs=nano.specs« in your Makefile), the code size can be reduced by 1.804 byte: 
 arm-none-eabi-size _build/Blebl_s110.elf
 text data bss dec hex filename
 14052 124 2076 16252 3f7c _build/Blebl_s110.elf
→ 14.176 byte flash size (plus 1k persistent config)

 
 Edit:
When using gcc link time optimization (-flto), the codesize again shrinks significantly (by about 3k): 
 arm-none-eabi-size _build/Blebl_s110.elf
 text data bss dec hex filename
 11056 124 2048 13228 33ac _build/Blebl_s110.elf
→ 11.180 byte flash size (plus 1k persistent config)

 
 Feedback is welcome.
@Nordic: Feel free to use that work in further sdk versions. 
 Edit 2015-04-20: Don't know why the devzone lost the attachments such often. Here is BleblGcc-V3.zip again.
Please note, that this work is done for Softdevice 6.0.0 and actually not ported to SoftDevice 7 and 8.

nRF51822 over the air bootloader with gcc

Top Replies

core_v2_widget.Hide()