Examples from SDK (ble_app_hrs_c)

Hi Lilian,

Did you dig further into where in nrf_sdh_enable_request() the return value 7 (NRF_ERROR_INVALID_PARAM) comes from? Looking at the implementation you can see that it can only come from the call to sd_softdevice_enable(). Further, looking at the API documentation for sd_softdevice_enable() you can see this relevant part:

 * @retval ::NRF_ERROR_INVALID_PARAM Invalid clock source configuration supplied in p_clock_lf_cfg.

 With this in mind I checked the sdk_config.h file you have attached here, but it looks good. Relevant section:

// <o> NRF_SDH_CLOCK_LF_SRC  - SoftDevice clock source.

// <0=> NRF_CLOCK_LF_SRC_RC
// <1=> NRF_CLOCK_LF_SRC_XTAL
// <2=> NRF_CLOCK_LF_SRC_SYNTH

#ifndef NRF_SDH_CLOCK_LF_SRC
#define NRF_SDH_CLOCK_LF_SRC 1
#endif

// <o> NRF_SDH_CLOCK_LF_RC_CTIV - SoftDevice calibration timer interval.
#ifndef NRF_SDH_CLOCK_LF_RC_CTIV
#define NRF_SDH_CLOCK_LF_RC_CTIV 0
#endif

// <o> NRF_SDH_CLOCK_LF_RC_TEMP_CTIV - SoftDevice calibration timer interval under constant temperature.
// <i> How often (in number of calibration intervals) the RC oscillator shall be calibrated
// <i>  if the temperature has not changed.

#ifndef NRF_SDH_CLOCK_LF_RC_TEMP_CTIV
#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 0
#endif

// <o> NRF_SDH_CLOCK_LF_ACCURACY  - External clock accuracy used in the LL to compute timing.

// <0=> NRF_CLOCK_LF_ACCURACY_250_PPM
// <1=> NRF_CLOCK_LF_ACCURACY_500_PPM
// <2=> NRF_CLOCK_LF_ACCURACY_150_PPM
// <3=> NRF_CLOCK_LF_ACCURACY_100_PPM
// <4=> NRF_CLOCK_LF_ACCURACY_75_PPM
// <5=> NRF_CLOCK_LF_ACCURACY_50_PPM
// <6=> NRF_CLOCK_LF_ACCURACY_30_PPM
// <7=> NRF_CLOCK_LF_ACCURACY_20_PPM
// <8=> NRF_CLOCK_LF_ACCURACY_10_PPM
// <9=> NRF_CLOCK_LF_ACCURACY_5_PPM
// <10=> NRF_CLOCK_LF_ACCURACY_2_PPM
// <11=> NRF_CLOCK_LF_ACCURACY_1_PPM

#ifndef NRF_SDH_CLOCK_LF_ACCURACY
#define NRF_SDH_CLOCK_LF_ACCURACY 7
#endif

Are you sure this is the sdk_config.h from the failing application? If it is, could it be that you redefine some of these defines elsewhere?

Hi Lilian,

Did you dig further into where in nrf_sdh_enable_request() the return value 7 (NRF_ERROR_INVALID_PARAM) comes from? Looking at the implementation you can see that it can only come from the call to sd_softdevice_enable(). Further, looking at the API documentation for sd_softdevice_enable() you can see this relevant part:

 * @retval ::NRF_ERROR_INVALID_PARAM Invalid clock source configuration supplied in p_clock_lf_cfg.

 With this in mind I checked the sdk_config.h file you have attached here, but it looks good. Relevant section:

// <o> NRF_SDH_CLOCK_LF_SRC  - SoftDevice clock source.

// <0=> NRF_CLOCK_LF_SRC_RC
// <1=> NRF_CLOCK_LF_SRC_XTAL
// <2=> NRF_CLOCK_LF_SRC_SYNTH

#ifndef NRF_SDH_CLOCK_LF_SRC
#define NRF_SDH_CLOCK_LF_SRC 1
#endif

// <o> NRF_SDH_CLOCK_LF_RC_CTIV - SoftDevice calibration timer interval.
#ifndef NRF_SDH_CLOCK_LF_RC_CTIV
#define NRF_SDH_CLOCK_LF_RC_CTIV 0
#endif

// <o> NRF_SDH_CLOCK_LF_RC_TEMP_CTIV - SoftDevice calibration timer interval under constant temperature.
// <i> How often (in number of calibration intervals) the RC oscillator shall be calibrated
// <i>  if the temperature has not changed.

#ifndef NRF_SDH_CLOCK_LF_RC_TEMP_CTIV
#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 0
#endif

// <o> NRF_SDH_CLOCK_LF_ACCURACY  - External clock accuracy used in the LL to compute timing.

// <0=> NRF_CLOCK_LF_ACCURACY_250_PPM
// <1=> NRF_CLOCK_LF_ACCURACY_500_PPM
// <2=> NRF_CLOCK_LF_ACCURACY_150_PPM
// <3=> NRF_CLOCK_LF_ACCURACY_100_PPM
// <4=> NRF_CLOCK_LF_ACCURACY_75_PPM
// <5=> NRF_CLOCK_LF_ACCURACY_50_PPM
// <6=> NRF_CLOCK_LF_ACCURACY_30_PPM
// <7=> NRF_CLOCK_LF_ACCURACY_20_PPM
// <8=> NRF_CLOCK_LF_ACCURACY_10_PPM
// <9=> NRF_CLOCK_LF_ACCURACY_5_PPM
// <10=> NRF_CLOCK_LF_ACCURACY_2_PPM
// <11=> NRF_CLOCK_LF_ACCURACY_1_PPM

#ifndef NRF_SDH_CLOCK_LF_ACCURACY
#define NRF_SDH_CLOCK_LF_ACCURACY 7
#endif

Are you sure this is the sdk_config.h from the failing application? If it is, could it be that you redefine some of these defines elsewhere?

Settings are not redefined elsewhere.

The call Stack:

- sd_softdevice_enable

- ser_sd_transport_open

- ser_hal_transport_open

- ser_phy_open

- nrf_drv_uart_init

- nrfx_uarte_init  ⇒ Return error 8 (NRFX_ERROR_INVALID_STATE)

I am confused. Why initialization of Bluetooth Need UARTE ?  It looks like a double initialization of UARTE.

First initialization done with "log_init".

Hi,

This is a different error than you described in the initial post (where nrf_sdh_enable_request() return error 7). Also, yere you are referring to ser_* APIs, which is serialization (see here). Serialization use UART or other serial interface as transport. Is that intentional?  Please elaborate.

The error is the same. After call function investigation, I have found that.

Function "ser_phy_open" transform the error returned by "nrf_drv_uart_init".

err_code = nrf_drv_uart_init(&m_uart, &m_uart_config, uart_event_handler);
if (err_code != NRF_SUCCESS)
{
    return NRF_ERROR_INVALID_PARAM;
}

The true error is error 8 from "nrfx_uarte_init". The example call these function in this order :

nrf_sdh_enable_request
{
    sd_softdevice_enable 
    {
        ser_sd_transport_open
        {
            ser_hal_transport_open
            {
                ser_phy_open
                {
                    nrf_drv_uart_init
                    {
                        nrfx_uarte_init
                        {
                            return 8 (NRFX_ERROR_INVALID_STATE)
                        }
                        return 7
                    }
                    return 7
                }
                return 7
            }
            return 7
        }
        return 7
    }
    return 7
}

The function "sd_softdevice_enable" return error 7 because of "nrfx_uarte_init".

Aha. But can you explain more what you are doing? Is it intentional that you use serialization (I suspect no as you wrote "Why initialization of Bluetooth Need UARTE")? Perhaps you can explain what you want to do, also please specify which exact project file you are using and which SDK config file you are using, and elaborate in general about your setup. Also, I recommend testing a debug build (with DEBUG defined), so that the error handler provides more information (then you will see the file name, line number an error code in the log<).

For my  application, I want to get information about "beacon" of Bluetooth devices in range of my module. I want my application run in the module nrf52832.

To start with Nordic SDK, I have tried to compile and tests some examples like "ble_app_hrs_c". The example does not work in my case and I created this ticket for it.

I guess I was wrong, since I can't compile now from a fresh restart with this Makefile from SDK:

"examples/ble_central/ble_app_hrs_c/pca10040/s132/armgcc/Makefile"

components/libraries/bsp/bsp_btn_ble.c:50:35: error: 'BSP_BUTTON_ACTION_RELEASE' undeclared (first use in this function)

I have opened the ticket when I used the "ser_s132_uart" version that I don't want to use.

Some points I learned:

- I didn't know "Serialization"  and I wasn't expected this feature. I don't want to use it for now, but it seems interesting, and I will maybe create a ticket for it if needed.

- I have created my custom header "custom_board.h" (no button, one led)

My goal:

I want just try Bluetooth Scan API and log information scanned with RTT to test it.