Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

No NRF_SDH_BLE_ENABLED check in ble_conn_state

Working on an application that can be compiled with BLE functionality turned on or off, I found my "BLE off" configuration failed to compile with the following error while compiling the ble_conn_state.c file:

static assertion failed: "NRF_SDH_BLE_ENABLED not set!"

The problem seems to be that this file checks for NRF_SDH_BLE_ENABLED to be set to 1 in the NRF_SDH_BLE_OBSERVER, showing the above compile time error if it is set to 0. NRF SDK examples that do not use BLE do not have this issue because they do not include this file in the project.

My application is based on the BLE UART (NUS) example, using NUS as an optional remote CLI interface. My current solution is to use a project setting to exclude this file based on the build configuration, but this is not very elegant or consistent with other NRF SDK modules.

What is the best approach to deal with the ble_conn_state file in projects that can be built with or without BLE / NRF_SDH_BLE_OBSERVER?

Is the ble_conn_state.c file missing a check like the folowing?

#if NRF_MODULE_ENABLED(NRF_BLE_CONN_PARAMS)

Parents Reply Children
  • seppestas said:

    Is it correct that this seems like a problem with / oversight in the NRF5 SDK?#

    I did not clarify it before, I'm using the NRF5 SDK v17.0.2 (d674dde).

     I think yes, few of the BLE modules seemed to have been overlooked in how they could be used in multibuild configuration. There is just one more minor release that will come after SDK17.0.2 and then it is an nRF5 SDK freeze. So I would not worry too much about upgrading issues with your changes. Nordic always gives the source code with the intention that the vendors and customers will modify them to their use case. We find out every day that some customer have a use case that we have not thought before and need to modify a driver or library to fit the new use case. So please do not resist yourself in making reasonable changes which are necessary in the new use cases like yours.

Related