• State Not Answered
  • Replies 9 replies
  • Subscribers 89 subscribers
  • Views 2512 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 281076
Options

Many warnings in the NRF SDK 17.1.0 when compiling with armgcc Makefile

Yohann

Hello,

Until now we compiled our company project using SEGGER Embedded Studio command line tool 'emBuild' that was called from a custom Makefile like this: 

emBuild -verbose -config "Debug_1" $(EMPROJECT_FILE)

But we would like to stop relying on SES and build our project with armgcc + Makefile directly.

So I set up a Makefile using the available examples of the sdk and made our project compile using it, so far it works great except one issue, there are many warnings (hundreds) in the SDK.

Most of these warnings come from the same two places in the code:

1. NRF_MODULE_ENABLED

For each call in any file of the sdk to this macro there is one warning generated that looks like this (-Wexpansion-to-defined): 

In file included from ../components/libraries/log/nrf_log_ctrl.h:58,
                 from ../components/libraries/log/nrf_log_str_formatter.h:53,
                 from ../components/libraries/log/src/nrf_log_backend_serial.c:43:
../components/libraries/log/src/nrf_log_ctrl_internal.h: At top level:
../components/libraries/log/src/nrf_log_ctrl_internal.h:50:1: warning: this use of "defined" may not be portable [-Wexpansion-to-defined]
   50 | #if NRF_MODULE_ENABLED(NRF_LOG)
      | ^~~~~~~~~~~~~~~

2. SVCALL

For each call in any file of the sdk to this macro there is one warning generated that looks like this (-Wunused-parameter): 

Compiling file: nrf_log_backend_uart.c
In file included from ../components/softdevice/s140/headers/nrf52/nrf_mbr.h:50,
                 from ../components/libraries/util/app_util.h:133,
                 from ../components/libraries/util/sdk_common.h:61,
                 from ../components/libraries/log/src/nrf_log_backend_uart.c:40:
../components/softdevice/s140/headers/nrf52/nrf_mbr.h: In function 'sd_mbr_command':
../components/softdevice/s140/headers/nrf52/nrf_mbr.h:257:67: warning: unused parameter 'param' [-Wunused-parameter]
  257 | SVCALL(SD_MBR_COMMAND, uint32_t, sd_mbr_command(sd_mbr_command_t* param));
      |                                                 ~~~~~~~~~~~~~~~~~~^~~~~
../components/softdevice/s140/headers/nrf_svc.h:76:22: note: in definition of macro 'SVCALL'
   76 |   static return_type signature                          \
      |                      ^~~~~~~~~

How can we get rid of these warnings ? They make seeing our code's warnings and errors impossible to see.

Thanks you,

Yohann

Parents
  • 0

    Hi Yohann,

    I am a bit surprised about these about the error you get from SVCALL for two reasons. This is API functions in a header file and should not lead to an error like this in any case. An also, we also have unused warnings in our Makefiles in the SDK, which does not complain about this (neither should it).

    Regarding the warnings you get for NRF_MODULE_ENABLED those defines should not be relevant.

    I agree whole heartedly that all code should build warning free, as the opposite would easily mask warnings you really should notice. But it seems the problem here is not in the code, but rather how you build (the options you pass to GCC). I suggest you use the Makefiles in the SDK as reference, where we use both -Wall and -Werror, which should be more than strict enough.

Reply
  • 0

    Hi Yohann,

    I am a bit surprised about these about the error you get from SVCALL for two reasons. This is API functions in a header file and should not lead to an error like this in any case. An also, we also have unused warnings in our Makefiles in the SDK, which does not complain about this (neither should it).

    Regarding the warnings you get for NRF_MODULE_ENABLED those defines should not be relevant.

    I agree whole heartedly that all code should build warning free, as the opposite would easily mask warnings you really should notice. But it seems the problem here is not in the code, but rather how you build (the options you pass to GCC). I suggest you use the Makefiles in the SDK as reference, where we use both -Wall and -Werror, which should be more than strict enough.

Children
Related