nrf52840dk: build fails with softdevice support

[attdona]

Description

I've tried to compile without success examples/hello-world demo for nrf52840dk board including nordic softdevice.

Steps to reproduce the issue

in examples/hello-world/Makefile I added:

 USEPKG = nordic_softdevice_ble

Actual results

"make" -C /home/adona/dev/RIOT/boards/common/nrf52xxxdk
In file included from /home/adona/dev/RIOT/examples/hello-world/bin/pkg/nrf52840dk/nordic_softdevice_ble/src/components/device/nrf.h:48:0,
                 from /home/adona/dev/RIOT/examples/hello-world/bin/pkg/nrf52840dk/nordic_softdevice_ble/src/components/softdevice/s1xx_iot/headers/nrf_soc.h:50,
                 from /home/adona/dev/RIOT/cpu/nrf52/include/cpu_conf.h:71,
                 from /home/adona/dev/RIOT/core/include/thread.h:125,
                 from /home/adona/dev/RIOT/cpu/cortexm_common/include/cpu.h:37,
                 from /home/adona/dev/RIOT/boards/common/nrf52xxxdk/board.c:21:
/home/adona/dev/RIOT/examples/hello-world/bin/pkg/nrf52840dk/nordic_softdevice_ble/src/components/device/nrf52.h:67:3: error: redeclaration of enumerator 'Reset_IRQn'
   Reset_IRQn                    = -15,              /*!<   1  Reset Vector, invoked on Power up and warm reset                 */
   ^

Versions

Operating system: Ubuntu
Build environment: arm-none-eabi-gcc (15:5.4.1+svn241155-1) 5.4.1 20160919

[kYc0o]

This is a well known issue, #6379 states something similar and we know it's broken since a while.

#8068 may solve these issues.

[attdona]

I think it is a new problem: not a buggy softdevice integration but a failure to compile.

Beside the type of error already reported there are a number of errors like this:

In file included from /home/adona/dev/RIOT/examples/hello-world/bin/pkg/nrf52840dk/nordic_softdevice_ble/src/components/device/nrf.h:48:0,
                 from /home/adona/dev/RIOT/examples/hello-world/bin/pkg/nrf52840dk/nordic_softdevice_ble/src/components/softdevice/s1xx_iot/headers/nrf_soc.h:50,
                 from /home/adona/dev/RIOT/cpu/nrf52/include/cpu_conf.h:71,
                 from /home/adona/dev/RIOT/core/include/thread.h:125,
                 from /home/adona/dev/RIOT/cpu/cortexm_common/include/cpu.h:37,
                 from /home/adona/dev/RIOT/boards/common/nrf52xxxdk/board.c:21:
/home/adona/dev/RIOT/examples/hello-world/bin/pkg/nrf52840dk/nordic_softdevice_ble/src/components/device/nrf52.h:492:3: error: conflicting types for 'NRF_UICR_Type'
 } NRF_UICR_Type;
   ^
In file included from /home/adona/dev/RIOT/cpu/nrf52/include/cpu_conf.h:29:0,
                 from /home/adona/dev/RIOT/core/include/thread.h:125,
                 from /home/adona/dev/RIOT/cpu/cortexm_common/include/cpu.h:37,
                 from /home/adona/dev/RIOT/boards/common/nrf52xxxdk/board.c:21:
/home/adona/dev/RIOT/cpu/nrf52/include/vendor/nrf52840.h:630:3: note: previous declaration of 'NRF_UICR_Type' was here
 } NRF_UICR_Type;
   ^

headers file are repeated in two different places, cpu/nrf52/include/vendor and softdevice package.

I'll investigate further ... are there some integration guideline or some good example to follow for external package integration in the build system?

[attdona]

The NRF IoT SDK downloaded form nordic is https://developer.nordicsemi.com/nRF5_IoT_SDK/nRF5_IoT_SDK_v0.9.x

This version does not support nrf52840 chip, headers file are out of date and cause include conflicts not easy to resolve (at least for me)

The latest SDK IoT version readme:

http://developer.nordicsemi.com/nRF5_IoT_SDK/nRF5_IoT_SDK_v1.0.x/

Shoud it be better to migrate to latest and stable SDK IoT release embedded into official nordic SDK?

[dylad]

Hi @attdona,
Since we're still working on a fix for the current SDK within RIOT (v0.9). I think it is a bit early to move to the new IoT SDK.
In fact, IoT SDK no longer exists and has been merged to the global Nordic SDK. I'm afraid it will take some time to get this new SDK working (as it introduces a lot of new features compare to the previous version).
My point of view would be to wait we fix all the current issues with the current softdevice and netif before moving to the new version of SDK.
I hope the softdevice will be fix for the end of the month.

[dylad]

I guess #9473 will solve this issue.

[pekkanikander]

In #9473 I don't have currently direct support for nrf52840dk with the SoftDevice, but adding that should not be too hard. I can try to make sure it compiles, but I don't have the newer DK and therefore I will not be able to test.

[pekkanikander]

Now I've added initial NRF52840DK SoftDevice support to #9473

[dylad]

nice, good job @pekkanikander
maybe @attdona can help you with #9473 now ?

[attdona]

Great Job!
I can do some test for this board.

The first feedback is about this build error from feature-update-nRF5-SDK-15.0.0:

cc1: error: /etc/alternatives/gcc-arm-none-eabi-include/newlib-nano: No such file or directory [-Werror=missing-include-dirs]
cc1: error: unrecognized command line option '-Wno-implicit-fallthrough' [-Werror]
cc1: all warnings being treated as errors

Is it related to #9381?

[pekkanikander]

Hi @attdona I haven't seen anything like that with #9473. It would be helpful if you run make with Q= so that the exact compile commands are shown, and copy-paste also them. Using triple backticks is probably a good idea for readability,

   like this

[attdona]

It works: I've patched makefiles/libc/newlib.mk with #9394.

I don't know if it is related with gcc version, by the way the problem arose with:

gcc version 6.3.1 20170620 (15:6.3.1+svn253039-1build1)

I've tested on another host with arm-none-eabi-gcc 7.2.1 and compilation succeeded without any patching.

[cladmi]

I updated the PR message and comments to put three "`" to get the multi line output.

@attdona could you try with this PR ? #9515

There are also some debug procedure in the PR comments, it would help if you could provide the output with this diff #9515 (comment) with and without the PR and the output of #9515 (comment)

I am trying to fix this globally and try to understand the different setups people have.

Thank you in advance.

[cladmi]

Just noticed that when you tested #9473, it was not rebased on master so maybe #9394 was not included. So it may be fixed now.

[attdona]

Correct, #9394 is not included in #9473.

The info you asked for (I'm using the standard arm-none-eabi-gcc package provided for ubuntu 18.04):

diff_without_PR9515.txt

diff_with_PR9515.txt

arm-none-eabi-gcc -v -x c -E /dev/null 2>&1

Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
Target: arm-none-eabi
Configured with: ../src/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:6.3.1+svn253039-1build1 --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=/build/gcc-arm-none-eabi-iopiMw/gcc-arm-none-eabi-6.3.1+svn253039=. -fstack-protector-strong' CPPFLAGS='-Wdate-time -D_FORTIFY_SOURCE=2' CXXFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-arm-none-eabi-iopiMw/gcc-arm-none-eabi-6.3.1+svn253039=. -fstack-protector-strong' FCFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-arm-none-eabi-iopiMw/gcc-arm-none-eabi-6.3.1+svn253039=. -fstack-protector-strong' FFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-arm-none-eabi-iopiMw/gcc-arm-none-eabi-6.3.1+svn253039=. -fstack-protector-strong' GCJFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-arm-none-eabi-iopiMw/gcc-arm-none-eabi-6.3.1+svn253039=. -fstack-protector-strong' LDFLAGS='-Wl,-Bsymbolic-functions -Wl,-z,relro' OBJCFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-arm-none-eabi-iopiMw/gcc-arm-none-eabi-6.3.1+svn253039=. -fstack-protector-strong' OBJCXXFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-arm-none-eabi-iopiMw/gcc-arm-none-eabi-6.3.1+svn253039=. -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 6.3.1 20170620 (15:6.3.1+svn253039-1build1) 
COLLECT_GCC_OPTIONS='-v' '-E'
 /usr/lib/gcc/arm-none-eabi/6.3.1/cc1 -E -quiet -v -D__USES_INITFINI__ /dev/null
ignoring nonexistent directory "/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/arm-none-eabi/6.3.1/include
 /usr/lib/gcc/arm-none-eabi/6.3.1/include-fixed
 /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/include
End of search list.
# 1 "/dev/null"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "/dev/null"
COMPILER_PATH=/usr/lib/gcc/arm-none-eabi/6.3.1/:/usr/lib/gcc/arm-none-eabi/6.3.1/:/usr/lib/gcc/arm-none-eabi/:/usr/lib/gcc/arm-none-eabi/6.3.1/:/usr/lib/gcc/arm-none-eabi/:/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/
LIBRARY_PATH=/usr/lib/gcc/arm-none-eabi/6.3.1/:/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/
COLLECT_GCC_OPTIONS='-v' '-E'

arm-none-eabi-gcc -v -x c -E /dev/null 2>&1 | grep '^\s'

 /usr/lib/gcc/arm-none-eabi/6.3.1/cc1 -E -quiet -v -D__USES_INITFINI__ /dev/null
 /usr/lib/gcc/arm-none-eabi/6.3.1/include
 /usr/lib/gcc/arm-none-eabi/6.3.1/include-fixed
 /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/include

[cladmi]

That you for the output. So your gcc looks like to output the supported things.

Can you confirm that know that #9473 has been ebased it compiles correctly ?

Sorry, I took some of your time for nothing as I was not clear enough. For the diff I meant to apply the diff I had in the comment #9515 (comment) that adds $(info) and compile to see the debug output.
But no worry, if the problem is fixed with the updated #9473 version it means it was just using one of the versions where if the build system did not correctly find newlib-nano it failed with No such file or directory instead of ignoring it as it was before.

[attdona]

On my side I can confirm!
greetings
Attilio

[kYc0o]

So, finally this issue will be solved by which PR?

[attdona]

This issue will be fixed by #9473

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[SemjonWilke]

As #9473 is closed by the stale bot, I'd like to know if this bug is still important to anyone involved with this issue?
In #6018 @Citrullin suggested removing the softdevice in favor of nimble.
Using nimble might make sense for your use cases and this issue could be resolved by dropping support for the softdevice.

EDIT: I just realized that the discussion in #13334 already went so far that they opted to remove the softdevice.

[miri64]

Leaving this for @bergzand as a reminder for next release, as the soft device is pending for removal then

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[miri64]

The softdevice was removed in #15326, so this issue is obsolete now.