Dimming Example Client on nRF52840 DK not detected by nRF Mesh Provisioning App.

[Armin]

An nRF5 SDK for Mesh v2.2.0 dimming example client running on a nRF52840 Preview DK is not detected for provisioning by a nRF Mesh smartphone provisioner.

Running the example in debuger delivers the following output on startup:

<t:          0>, main.c,  353, ----- BLE Mesh Light Switch Client Demo -----
<t:          0>, mesh_softdevice_init.c,  117, Initializing SoftDevice...
<t:          0>, mesh_softdevice_init.c,   75, Enabling BLE...
<t:         16>, mesh_softdevice_init.c,  109, sd_ble_enable: app_ram_base should be adjusted to 0x20002DA0
<t:        479>, main.c,  320, Initializing and adding models
<t:       5328>, main.c,  385, Device UUID : 0059CCBB0000000050B5B3E4BD11F856

[awneil]

Armin said:

app_ram_base should be adjusted to 0x20002DA0

So have you done that, then?

[Armin]

No. Please can you assist me how to do that?

However, I doubt if this is the reason for the reported issue because it is just a warning.

I'm wondering if you ever have tested the dimming example client on a nRF52840 Preview DK with nRF Mesh smartphone provisioner. I use all parts of the firmware and app exactly as you provide them without any change and they don't run. That lets me doubt if you ever have tested it.

[awneil]

https://devzone.nordicsemi.com/b/blog/posts/segger-embedded-studio-a-cross-platform-ide - scroll down to the bit about FLASH_START and SRAM_START

This may also help:

https://devzone.nordicsemi.com/tutorials/b/software-development-kit/posts/rom-and-ram-management

[Armin]

Thank you for your tip, but it does not solve the issue unfortunately.

[awneil]

Do you mean it doesn't get rid of the message?

Or getting rid of the message doesn't fix the issue of not being detected?

[Armin]

The message still exists and the issue not being detected is still there.

I guess the instructions in the given links are not correct. However, I found the correct place in SEGGER IDE where to set the "app_ram_base" to the required value 0x20002DA0. it is here:

Now the warning message has disappeared.

However, the issue of not being detected is still there!

What is besides quite confusing in this example is the following:

According to the examples description it is possible to "Instead of using a provisioner board, you can also use the nRF Mesh app:". However, in code nrf_mesh_config_core.h there are following definitions:

/** GATT feature, should only be enabled in combination with linking GATT files. */
#ifndef MESH_FEATURE_GATT
#define MESH_FEATURE_GATT 0
#endif

/** GATT proxy feature, should only be enabled in combination with linking GATT proxy files. */
#ifndef GATT_PROXY
#define GATT_PROXY 0
#endif

Which means, provisioning via nRF Mesh App is not supported as this would require GATT Proxy feature.

[Bjørn Kvaale]

Update 2: Below is the preprocessor definition for the light switch proxy client example. If you compare that with the experimental dimming client preprocessor definition, you notice that MESH_FEATURE_GATT=1 & GATT_PROXY=1 are missing (which you correctly pointed out).

As you have correctly pointed out, MESH_FEATURE_GATT & GATT_PROXY are not defined in the dimming example.

Once these preprocessor definitions are defined, it can be helpful to close the Segger project & open it up again. That way, the sections that were uncommented under #if MESH_FEATURE_GATT should not be grayed out anymore.

I had to add the following files:

nrf_sdh.c into the Others folder. The c file can be found here: 

nrf5_SDK_for_Mesh_v2.2.0_src\external\sdk_fix

I also added nrf_sdh_ble.c from (added it to the nRF5 SDK folder):

nRF5_SDK_15.0.0_a53641a\components\softdevice\common

I also added the ble_conn_params.c folder from:

nRF5_SDK_15.0.0_a53641a\components\ble\common

The ble_srv_common.c was also added to nRF5 SDK (path: nRF5_SDK_15.0.0_a53641a\components\ble\common)

Also add ble_advdata.c (path: C:\NordicSemi\SDKs\nRF5_SDK_15.0.0_a53641a\components\ble\common)

I then also added the following c files to a new GATT folder (proxy_filter.c, mesh_gatt.c & proxy.c). The files can be found here:

nrf5_SDK_for_Mesh_v2.2.0_src\mesh\gatt\src

I also added nrf_mesh_prov_bearer_gatt.c into the Provisioning folder (see path: nrf5_SDK_for_Mesh_v2.2.0_src\mesh\prov\src)

nrf_section_iter.c was added into the nRF5 SDK folder (path: nRF5_SDK_15.0.0_a53641a\components\libraries\experimental_section_vars)

mesh_adv.c was added into the Application folder (path: nrf5_SDK_for_Mesh_v2.2.0_src\examples\common\src)

Then, I had to add the following header files & make the code changes below:

In main.c:

added following defines after APP_UNACK_MSG_REPEAT_COUNT (2):

#define DEVICE_NAME                     "nRF5x Mesh Switch"
#define MIN_CONN_INTERVAL               MSEC_TO_UNITS(150,  UNIT_1_25_MS)           /**< Minimum acceptable connection interval. */
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(250,  UNIT_1_25_MS)           /**< Maximum acceptable connection interval. */
#define SLAVE_LATENCY                   0                                           /**< Slave latency. */
#define CONN_SUP_TIMEOUT                MSEC_TO_UNITS(4000, UNIT_10_MS)             /**< Connection supervisory timeout (4 seconds). */
#define FIRST_CONN_PARAMS_UPDATE_DELAY  APP_TIMER_TICKS(100)                        /**< Time from initiating event (connect or start of notification) to first time sd_ble_gap_conn_param_update is called. */
#define NEXT_CONN_PARAMS_UPDATE_DELAY   APP_TIMER_TICKS(2000)                       /**< Time between each call to sd_ble_gap_conn_param_update after the first call. */
#define MAX_CONN_PARAMS_UPDATE_COUNT    3                                           /**< Number of attempts before giving up the connection parameter negotiation. */

static void gap_params_init(void);
static void conn_params_init(void);

added header files under Core comment in main.c:

#include "mesh_adv.h" // added by BK
#include "nrf_sdh.h" // added by BK
#include "ble_conn_params.h" // added by BK
#include "proxy.h" // added by BK

added gap_params_init() & conn_params_init() right below mesh_init():

static void gap_params_init(void) // added by BK
{
    uint32_t                err_code;
    ble_gap_conn_sec_mode_t sec_mode;

    BLE_GAP_CONN_SEC_MODE_SET_OPEN(&sec_mode);

    err_code = sd_ble_gap_device_name_set(&sec_mode,
                                          (const uint8_t *) DEVICE_NAME,
                                          strlen(DEVICE_NAME));
    APP_ERROR_CHECK(err_code);
}

static void conn_params_init(void)
{
    uint32_t               err_code;
    ble_conn_params_init_t cp_init;
    ble_gap_conn_params_t  gap_conn_params;

    memset(&gap_conn_params, 0, sizeof(gap_conn_params));
    gap_conn_params.min_conn_interval = MIN_CONN_INTERVAL;
    gap_conn_params.max_conn_interval = MAX_CONN_INTERVAL;
    gap_conn_params.slave_latency     = SLAVE_LATENCY;
    gap_conn_params.conn_sup_timeout  = CONN_SUP_TIMEOUT;

    err_code = sd_ble_gap_ppcp_set(&gap_conn_params);
    APP_ERROR_CHECK(err_code);

    memset(&cp_init, 0, sizeof(cp_init));
    cp_init.p_conn_params                  = &gap_conn_params;
    cp_init.first_conn_params_update_delay = FIRST_CONN_PARAMS_UPDATE_DELAY;
    cp_init.next_conn_params_update_delay  = NEXT_CONN_PARAMS_UPDATE_DELAY;
    cp_init.max_conn_params_update_count   = MAX_CONN_PARAMS_UPDATE_COUNT;
    cp_init.start_on_notify_cccd_handle    = BLE_GATT_HANDLE_INVALID;
    cp_init.disconnect_on_fail             = false;
    cp_init.evt_handler                    = on_conn_params_evt;
    cp_init.error_handler                  = conn_params_error_handler;

    err_code = ble_conn_params_init(&cp_init);
    APP_ERROR_CHECK(err_code);
}

added on_conn_params_evt() & conn_params_error_handler() below models_init_cb in main.c

static void on_conn_params_evt(ble_conn_params_evt_t * p_evt)
{
    uint32_t err_code;

    if (p_evt->evt_type == BLE_CONN_PARAMS_EVT_FAILED)
    {
        err_code = sd_ble_gap_disconnect(p_evt->conn_handle, BLE_HCI_CONN_INTERVAL_UNACCEPTABLE);
        APP_ERROR_CHECK(err_code);
    }
    else if (p_evt->evt_type == BLE_CONN_PARAMS_EVT_SUCCEEDED)
    {
        __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Successfully updated connection parameters\n");
    }
}

static void conn_params_error_handler(uint32_t nrf_error)
{
    APP_ERROR_HANDLER(nrf_error);
}

In app_config.h, I added the following lines under

/** Override default sdk_config.h values. */

C:\NordicSemi\SDKs\nRF5_SDK_15.0.0_a53641a\components\libraries\experimental_log\src\nrf_log_internal.h

In the preprocessor definitions, I had to add the following lines:

$(SDK_ROOT:../../../../nRF5_SDK_15.0.0_a53641a)/components/softdevice/common

$(SDK_ROOT:../../../../nRF5_SDK_15.0.0_a53641a)/components/libraries/experimental_log

$(SDK_ROOT:../../../../nRF5_SDK_15.0.0_a53641a)/components/libraries/experimental_log/src

$(SDK_ROOT:../../../../nRF5_SDK_15.0.0_a53641a)/components/libraries/strerror

$(SDK_ROOT:../../../../nRF5_SDK_15.0.0_a53641a)/components/ble/common

$(SDK_ROOT:../../../../nRF5_SDK_15.0.0_a53641a)/components/libraries/atomic

In nrf_sdh.c, I also commented out this code:

//void SD_EVT_IRQHandler(void)
//{
// nrf_sdh_evts_poll();
//}

Summary: As you can see, quite a few changes were made to integrate the proxy functionality into this example.

I have gotten the experimental dimming example to build correctly, but unfortunately there is still an issue with identifying the different elements & other parameters when testing with the nRF Mesh for iOS app. There is a similar issue for Android. I have not figured this out yet, but will continue looking at the issue.

I would recommend making the same changes that I made & try to figure out what the issue could be yourself too.

Update: The below info is wrong. Embarrassingly enough I provisioned someone elses DK, while I thought it was mine. You are correct that proxy & gatt is not enabled. This issue has been reported internally a week or so ago & should make it out into the next mesh release. I will take a closer look & get back to you on a fix for sdk v2.2.0.

Wrong Info Here:

I have just tested this example with mesh sdk v2.2.0 & the nRF Mesh app for iOS & I was able to provision & configure the experimental dimming client example successfully. I did not make any changes to the regular example.

Did you set the Mesh SDK & nRF5 SDK paths (i.e. SDK_ROOT & MESH_ROOT) correctly in Tools -> Options -> Building -> Global Macros.

Are you using nRF Mesh for Android? What phone are you using? Have you tried clearing the Bluetooth cache (turn Bluetooth off for 10 seconds or so & then turn Bluetooth back on) before trying to provision via nRF Mesh?

I am also using Segger Embedded Studio v3.40.

Kind Regards,

Bjørn

[Armin]

Ok, so I'm looking forward to hear from you for a fix for SDK v2.2.0.

Thank you for your support.

[Armin]

I guess the same applies for the "EnOcean switch translator client demo", right?

Will this also be considered in the next mesh release?

[Bjørn Kvaale]

Armin said:

I guess the same applies for the "EnOcean switch translator client demo", right?

 I do not fully understand. Does the example not work or do you somehow want to integrate the proxy node into this example?

If you are wondering what could make it into the next mesh release or the next mesh release data, please contact your local Regional Sales Manager. If you are unsure who this is, send me a private message & I can put you in touch.

[Armin]

Yes, the question was, if the proxy fuctionality could also be integrated to the EnOcean switch translator client demo.

[Armin]

I do not understand what is meant in your instruction above with:

Bjørn Kvaale said:

In app_config.h, I added the following lines under

/** Override default sdk_config.h values. */

C:\NordicSemi\SDKs\nRF5_SDK_15.0.0_a53641a\components\libraries\experimental_log\src\nrf_log_internal.h

For now I ignored this instruction and it is possible to build correctly. However when running the example on an nRF52840-DK there is an error:

<t:       5555>, app_error_weak.c,   95, Mesh assert at 0x0003E792 (:0)