nRF51822 over the air bootloader with gcc

[Joe Merten]

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.

[Samuele Forconi]

Hi, thanks for sharing both your codes. I'm working on both OSX and Linux, and I've made some modifications (more or less like the ones made by Nikita) to make the bootloader code compile with gcc. I build the code with the standard gcc configuration (not hlnd/pure-gcc).

The problem is that using 0x3C000 as BOOTLOADER_REGION_START, with FLASH (rx) : ORIGIN = 0x0003C000, LENGTH = 0x4000 ends with:

_build/dfu_single_bank_ble_s110.out section `.text' will not fit in region `FLASH'
...
ld: region `FLASH' overflowed by 10600 bytes

My current Makefile is this:

TARGET_CHIP := NRF51822_QFAA_CA
BOARD := BOARD_NRF6310
CFLAGS += -DBLE_STACK_SUPPORT_REQD -DBOOTLOADER_BANKED

SDK_PATH = /opt/nrf51/nrf51_sdk_v5_2_0_39364/nrf51822/

C_SOURCE_FILES = main.c
C_SOURCE_FILES += bootloader_util_arm.c
C_SOURCE_FILES += bootloader.c
C_SOURCE_FILES += dfu_single_bank.c
C_SOURCE_FILES += dfu_transport_ble.c

C_SOURCE_FILES += $(SDK_PATH)Source/app_common/app_timer.c
C_SOURCE_FILES += $(SDK_PATH)Source/app_common/app_scheduler.c
C_SOURCE_FILES += $(SDK_PATH)Source/app_common/app_gpiote.c
C_SOURCE_FILES += $(SDK_PATH)Source/app_common/crc16.c
C_SOURCE_FILES += $(SDK_PATH)Source/sd_common/softdevice_handler.c
C_SOURCE_FILES += $(SDK_PATH)Source/app_common/pstorage.c
C_SOURCE_FILES += $(SDK_PATH)Source/app_common/hci_mem_pool.c

C_SOURCE_FILES += $(SDK_PATH)Source/ble/ble_conn_params.c
C_SOURCE_FILES += $(SDK_PATH)Source/ble/ble_advdata.c
C_SOURCE_FILES += $(SDK_PATH)Source/ble/ble_services/ble_srv_common.c
C_SOURCE_FILES += $(SDK_PATH)Source/ble/ble_services/ble_dfu.c

INCLUDEPATHS += -I"../include"
INCLUDEPATHS += -I"../include/ble_transport"
INCLUDEPATHS += -I"$(SDK_PATH)Include/ble"
INCLUDEPATHS += -I"$(SDK_PATH)Include/s110"
INCLUDEPATHS += -I"$(SDK_PATH)Include/app_common"
INCLUDEPATHS += -I"$(SDK_PATH)Include/ble/ble_services"
INCLUDEPATHS += -I"$(SDK_PATH)Include/sd_common"

OUTPUT_FILENAME := dfu_single_bank_ble_s110

# Use custom linker script
LINKER_SCRIPT := gcc_nrf51_s110_xxaa_bl.ld

CFLAGS += -Os -flto -ffunction-sections -fdata-sections -fno-builtin
LDFLAGS += --specs=nano.specs -lc -lnosys -Wl,--gc-sections

include $(SDK_PATH)Source/templates/gcc/Makefile.common

Have you experienced these problems with executable size when dealing with bootloader code at 0x3C000? Are there any compiler settings to set to reduce code size to fit at 0x3C000?

Thanks for any help.

Samuele.

[Samuele Forconi]

I managed to make it reduce the code size of the executable. The problem was that the -Os compiler flag wasn't set in the final Makefile, now I've made some mods and the resulting executable size is: text data bss dec hex 12610 1128 1972 15710 3d5e

Remains the problem that the final .bin file size is 256MB and I'm still investigating how to split the UICR section from the rest of the executable and program the two sections separately (as is done with s110 softdevice).

[Nikita]

Try to compile your code without additional flags: -flto -ffunction-sections -fdata-sections -fno-builtin and --specs=nano.specs -lc -lnosys -Wl,--gc-sections This compiler flags only makes your code larger. I don't understand how is your final .bin file size is 256MB though. About writing to the UICR section look at this: https://devzone.nordicsemi.com/index.php/application-with-softdevice-have-to-put-at-address-0x14000 In SDK 5.2 compared to SDK 5.1 DFU code got bigger. For dual bank BLE DFU I got now: 'Invoking: Cross ARM GNU Print Size' arm-none-eabi-size --format=berkeley "nRF51822_BLE_DFU.elf" text data bss dec hex filename 14732 2128 2100 18960 4a10 nRF51822_BLE_DFU_single_bank.elf 'Finished building: nRF51822_BLE_DFU.siz' And I had to increase the size of flash section: FLASH (rx) : ORIGIN = 0x3BC00, LENGTH = 0x4000 /* bootloader */ #define BOOTLOADER_REGION_START 0x0003BC00

[Samuele Forconi]

Hi Nikita, thanks for your answer. Like Ole Morten told me in this post: https://devzone.nordicsemi.com/index.php/compiling-nrf51822-bootloader-example-using-gcc it seems that the .bin files doesn't allow jumps, so keeping the uicr write at address 0x10001014 makes the code increase to around 256MB. If I remove the KEEP from UICR section in the linker script, the code reduce to a few KB.

In the post you have linked, I see that it's possible to use the nrfjprog tool to pre-program the UICR.BOOTLOADERADDR register, like this: nrfjprog --memwr 0x10001014 --val 0x3C000

So, maybe it's possible to remove the m_uicr_bootloader_start_address from the source file and the ".bootloader_address" section from the linker script and only use the nrfjprog tool to program the bootloader address before installing the bootloader firmware...

[Nikita]

Why are you using the .bin format then? Why not .hex?

[Samuele Forconi]

Well, there's no special reason... the build process outputs a .bin, a .hex and a .out file. Then I used a script (like the one provided with pure-gcc) to flash the executable to the nRF51. This script load the .bin file and flashes the chip using the JLink tool. If it would be possible to use the .hex file as the input file to flash, I would not use anymore the .bin...