Problem building DFU example, SDK10

[Lisandro Damián Nicanor Pérez Meyer]

I am currently working with an nRF51822, SDK 10 (can't be changed), s110. I have a nRf51822-DK (aka pca10028) and wanted to try the dfu_dual_bank_ble_s110_pca10028 example compiling with armgcc. (nRF51_SDK_10.0.0_dc26b5e/examples/dfu/bootloader/pca10028/dual_bank_ble_s110/armgcc to be more precise).

So far I had no issues with other examples but when compiling this particular example:

lisandro@tonks:/opt/nRF51_SDK_10.0.0_dc26b5e/examples/dfu/bootloader/pca10028/dual_bank_ble_s110/armgcc$ make
rm -rf _build
echo  Makefile
Makefile
mkdir _build
Compiling file: app_error.c
Compiling file: app_scheduler.c
Compiling file: app_timer.c
Compiling file: app_timer_appsh.c
Compiling file: bootloader.c
Compiling file: bootloader_settings.c
Compiling file: bootloader_util.c
Compiling file: crc16.c
Compiling file: dfu_dual_bank.c
Compiling file: dfu_init_template.c
Compiling file: dfu_transport_ble.c
Compiling file: hci_mem_pool.c
Compiling file: nrf_assert.c
Compiling file: nrf_delay.c
Compiling file: pstorage_raw.c
Compiling file: dfu_ble_svc.c
Compiling file: main.c
Compiling file: ble_advdata.c
Compiling file: ble_conn_params.c
Compiling file: ble_dfu.c
Compiling file: ble_srv_common.c
Compiling file: system_nrf51.c
Compiling file: softdevice_handler.c
Compiling file: softdevice_handler_appsh.c
Compiling file: gcc_startup_nrf51.s
Linking target: nrf51422_xxac.out
/usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: _build/nrf51422_xxac.out section `.text' will not fit in region `FLASH'
/usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: section .bootloaderSettings VMA [000000000003fc00,000000000003ffff] overlaps section .text VMA [000000000003c000,000000000003fc1f]
/usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: section .ARM.exidx VMA [000000000003fc20,000000000003fc27] overlaps section .bootloaderSettings VMA [000000000003fc00,000000000003ffff]
/usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: region `FLASH' overflowed by 40 bytes
collect2: error: ld returned 1 exit status
make: *** [Makefile:164: nrf51422_xxac] Error 1

Normally this would mean that the device can't hold the bootloader due to it's size, but as far as I understand pca10028 should have enough memory for it.

I'm using Debian's testing/unstable gcc for arm-none-eabi:

$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-none-eabi/7.3.1/lto-wrapper
Target: arm-none-eabi
Configured with: ../configure --build=x86_64-linux-gnu --prefix=/usr --includedir='/usr/lib/include' --mandir='/usr/lib/share/man' --infodir='/usr/lib/share/info' --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir='/usr/lib/lib/x86_64-linux-gnu' --libexecdir='/usr/lib/lib/x86_64-linux-gnu' --disable-maintainer-mode --disable-dependency-tracking --mandir=/usr/share/man --enable-languages=c,c++,lto --enable-multilib --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --build=x86_64-linux-gnu --target=arm-none-eabi --with-system-zlib --with-gnu-as --with-gnu-ld --with-pkgversion=15:7-2018-q2-6 --without-included-gettext --prefix=/usr/lib --infodir=/usr/share/doc/gcc-arm-none-eabi/info --htmldir=/usr/share/doc/gcc-arm-none-eabi/html --pdfdir=/usr/share/doc/gcc-arm-none-eabi/pdf --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --disable-libstdc++-v3 --host=x86_64-linux-gnu --with-headers=no --without-newlib --with-multilib-list=rmprofile CFLAGS='-g -O2 -fdebug-prefix-map=/tmp/building/package=. -fstack-protector-strong' CPPFLAGS='-Wdate-time -D_FORTIFY_SOURCE=2' CXXFLAGS='-g -O2 -fdebug-prefix-map=/tmp/building/package=. -fstack-protector-strong' FCFLAGS='-g -O2 -fdebug-prefix-map=/tmp/building/package=. -fstack-protector-strong' FFLAGS='-g -O2 -fdebug-prefix-map=/tmp/building/package=. -fstack-protector-strong' GCJFLAGS='-g -O2 -fdebug-prefix-map=/tmp/building/package=. -fstack-protector-strong' LDFLAGS=-Wl,-z,relro OBJCFLAGS='-g -O2 -fdebug-prefix-map=/tmp/building/package=. -fstack-protector-strong' OBJCXXFLAGS='-g -O2 -fdebug-prefix-map=/tmp/building/package=. -fstack-protector-strong' INHIBIT_LIBC_CFLAGS=-DUSE_TM_CLONE_REGISTRY=0 AR_FOR_TARGET=arm-none-eabi-ar AS_FOR_TARGET=arm-none-eabi-as LD_FOR_TARGET=arm-none-eabi-ld NM_FOR_TARGET=arm-none-eabi-nm OBJDUMP_FOR_TARGET=arm-none-eabi-objdump RANLIB_FOR_TARGET=arm-none-eabi-ranlib READELF_FOR_TARGET=arm-none-eabi-readelf STRIP_FOR_TARGET=arm-none-eabi-strip
Thread model: single
gcc version 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907] (15:7-2018-q2-6)

Just in case I missed something I re downloaded the SDK and diffed it against my original one. The only difference is in components/toolchain/gcc/Makefile.posix, which is modified to use the system's arm-none-eabi compiler.

So the question is: what am I missing here?

[Sigurd]

Hi,

Have you done any changes to the bootloader files, or to the dfu_gcc_nrf51.ld file ?

We have seen some issues with GCC version 7 when link time optimization (LTO) is enabled. Are you building the bootloader with the "-flto" option? If so, can you see if removing it helps? (See this post)

Note that we used GCC ARM Embedded 4.9 2015q1 for testing and verification of SDK 10.

[Lisandro Damián Nicanor Pérez Meyer]

Sigurd said:

Could you try to download a fresh copy of SDK 10 from here, and see if it builds?

I did before filing this case, to no avail.

Sigurd said:

If it does not build, then test with GCC ARM Embedded 4.9 2015q1 

I could, but it won't help me: this is part of an upgrade to an already existing development which uses the current compiler. Switching back to such an old compiler will surely mean lots of tests to already deployed devices.

[Sigurd]

But in order to find the root cause of the issue, it would be beneficial to know if using the 4.9 2015q1 resolves the issue. Also running make with verbose logging(make VERBOSE=1) could provide useful information during linking(e.g. to see that the correct optimization flags are being set).

[Lisandro Damián Nicanor Pérez Meyer]

Solves the issue. Sorry for the long delay. Client accepted the risk of going back to old compiler...