bootloader does not work if compiled using armgcc

[Elias Löwe]

Hello!

SDK 15.3

If I build secure_bootloader example project using Segger Embedded Studio it works, I can see it nRF connect.

If I build it using armgcc it does not work and I can not attach Ozone debugger to it.

The only change I did to project is disabled `#ifdef NRF_DFU_DEBUG_VERSION ` check in  `dfu_public_key.c`

The sequence:

cd sdk/examples/dfu/secure_bootloader/pca10040_ble/armgcc

make

make erase

make flash_softdevice

make flash

GCC:

> arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/arm-none-eabi/7.1.0/lto-wrapper
Target: arm-none-eabi
Configured with: ../gcc-7.1.0/configure --prefix=/usr --mandir=/usr/share/man --with-pkgversion='Fedora 7.1.0-5.fc27' --with-bugurl=https://bugzilla.redhat.com/ --infodir=/usr/share/info --target=arm-none-eabi --enable-interwork --enable-multilib --with-python-dir=share/arm-none-eabi/gcc-7.1.0/python --with-multilib-list=rmprofile --enable-plugins --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --enable-languages=c,c++ --with-newlib --disable-nls --disable-shared --disable-threads --with-gnu-as --with-gnu-ld --with-gmp --with-mpfr --with-mpc --with-headers=yes --with-system-zlib --with-sysroot=/usr/arm-none-eabi
Thread model: single
gcc version 7.1.0 (Fedora 7.1.0-5.fc27)

But also tried `gcc version 8.2.1 20181213 (release) [gcc-8-branch revision 267074] (GNU Tools for Arm Embedded Processors 8-2018-q4-major)` with the same result.

If I flash it using procedure above and then attach debugger from SES, I see:

Unknown function at 0xFFFFFFFE

Need assistance

[Elias Löwe]

Yesterday I've found the solution or workaround:

I've changed in secure_bootloader_gcc_nrf52.ld 

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
}

to

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

taken from older SDK.

Please confirm if it is safe solution or suggest correct one?

[Sigurd]

Hi,

The reason why --sectorerase is erasing the MBR(0x0 to 0x1000), is that the bootloader in SDK 15.3 stores the uicr_bootloader_start_address and uicr_mbr_params_page in the MBR part of the flash (0x0FF8 and 0x0FFC ). See this page. --sectorerase then erases the whole page(0x0 to 0x1000) before writing the hex file. The make flash and make flash_softdevice commands have unfortunately not been updated to reflect this change in SDK 15.3

A workaround is then to use mergehex, and merge the SoftDevice hex(it includes the MBR) and the application/bootloader hex. You can change the makefile to include something like this:

# Flash softdevice and app
flash_softdevice_and_app:
	@echo Flashing: s132_nrf52_6.1.1_softdevice.hex and app
	mergehex -m $(OUTPUT_DIRECTORY)/nrf52832_xxaa_s132.hex $(SDK_ROOT)/components/softdevice/s132/hex/s132_nrf52_6.1.1_softdevice.hex -o sd_app.hex
	nrfjprog -f nrf52 --program sd_app.hex --sectorerase
	nrfjprog -f nrf52 --reset

and then use make flash_softdevice_and_app, to flash both the SoftDevice and the bootloader.

[Eliot Stock]

Why did you not rename uicr_bootloader_start_address at the same time? It is no longer in the UICR, so the name is very confusing.

[Sigurd]

Hi Eliot,

The main reason for this was convenience. I agree that the name is now confusing, and I have requested the name to be updated in the next SDK release.