This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Conflicting "nrf_errno.h" resulting in compilation error

MCU: nrf5340 Network Core
nRF Connect SDK Version: 1.5.1

Currently there are multiple libraries under ncs/nrfxlib that have their own "nrf_errno.h".
Out of those libraries, our application needs softdevice_controller, mpsl, and nrf_rpc libraries. 

Basically, we are trying to merge functionalities of two sample codes (listed below) for nrf5340 network core firmware.

1) zephyr/samples/bluetooth/hci_rpmsg
2) nrf/samples/nrf_rpc/entropy_nrf53/cpunet

While porting the code of "entropy_nrf53/cpunet" to "hci_rpmsg" sample, we ran into compilation issues where some of the error codes defined in "nrf_errno.h" weren't declared.

By default, the build environment always points to the "nrf_errno.h" residing under ncs/nrfxlib/mpsl/include folder, while source code written in nrf_rpc library uses error codes that aren't defined in mpsl version.

We are already aware of following ways we can resolve this issue:

1) Delete "nrf_errno.h" under mpsl, and softdevice_controller.
2) Modify include line in nrf_rpc source files to specify specific path of "nrf_errno.h"
3) Modify "nrf_rpc" libraries to use generic zephyr "errno.h" codes

Problem is that all of these solution requires modifying the SDK files, which we want to avoid. 

Please advice on how to resolve this conflict without modifying the nrf_rpc library directly.  


Firmware zip:

2783.net_core.zip

Parents Reply Children
  • Hello again!

    Thanks for the provided code. I've gotten some info back from R&D regarding the issue. Firstly they say that there currently isn't any easy way to avoid this without modifying source code. This is known and there are plans for improving this in the future. 

    They also pointed out that there currently it's not possible to combine the hci_rpmsg sample with samples using nRF RPC (like entropy_nrf53/cpunet) without doing modifications to source code (like the Inter-processor messaging driver and RPC driver). Without modifications there will be conflicts in the shared memory access. Work is being done in this PR to facilitate for several instances of inter-core communication, but this is still a work in progress and the samples/source code must be adjusted to the new API.

    Apologies for the inconvenience.

    Best regards,
    Carl Richard

  • Hi Carl,

    Well that sucks. Anyway, thanks for the help. Glad to know its being worked on. 

Related