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?

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<).