Remote provisioning server integration problem

[Gianluca]

Hello friends,

i'm trying to add the pb_remote server functionality to a project without success, i kindly ask for some advices.

Development tools:

SDKs:

nRF5 SDK 17.0.2

nrf5 SDK for Mesh v5.0.0

The application integrates the the two DSKs, the application implements a proprietary mesh model to manage some custom devices

The application implements advertising and communication with mobile devices using NUS service. The device provisioning is managed by a custom mobile application.

Nowday we need to add the pb_remote_server model to every mesh node with the purpose of performing the provisioning of the mesh network devices from a single centralized point.

We added the remote server provisioning functionality starting from the mesh sdk example. The application builds and run correctly but no Unprovisioned device beacon packets are visible on the BLE sniffer. This kind of packets are visible with the pb_remote_server application instead.

We have made some unsuccessfully tests disabling the BLE advertising for mobile devices communication and disabling the initialization of our custom mesh models leaving only the remote_server one.

Following the code with breakpoints, we have seen that the function
void advertiser_packet_send(advertiser_t * p_adv, adv_packet_t * p_packet)
in the module nrf5_SDK_for_Mesh_v5.0.0\mesh\bearer\src\advertiser.c

is correctly called but the callback function in the same module:

static void tx_complete_event_callback(void * p_context)

is never called (in the pb_remote_server example it is called after the packet's send).

This is the call stack:

and this is part of the advertiser_t data structure passed to the function advertiser_packet_send

We will continue with testing, any help will be very appreciated.

Best regards,

Gianluca.

[AHaug]

Hi,

Apologies for the late response. This is due to the Easter Holidays that spanned the previous week and half in Norway.

I've discussed the symptoms your observing with our Mesh team, and we suspect that what you're observing is due to the BLE stack not being fully intiialized. We suggest you to look at the sdk coex examples (ble_app_proximity_coexist and ble_app_uart_coexist). In pb_remote_server we call ble_stack_init() from examples/common/src/ble_sorftdevice_support.c, but for coex examples, ble stack is initialized slightly different (for example see ble_stack_init() in examples/sdk_coexist/ble_app_proximity_coexist/main.c

Another possible cause could be that NRF_SDH_SOX_OBSERVER is not registered and events are not passed to nrf_mesh_on_sd_evnt (see NRF_SDH_SOC_OBSERVER in ble_softdevice_support.c and in mesh_main.c of the coex examples.

Let me know if any of this solves the issues you're having or if you've solved the issue while waiting from a response from us.

Kind regards,
Andreas

[Gianluca]

Hi Andreas, thanks for the answer.

I already use the ble_stack_init() from the coexistance example, this is my function:

static void ble_stack_init(void)
{
ret_code_t err_code;

err_code = nrf_sdh_enable_request();
APP_ERROR_CHECK(err_code);

// Configure the BLE stack using the default settings.
// Fetch the start address of the application RAM.
uint32_t ram_start = 0;
err_code = nrf_sdh_ble_default_cfg_set(APP_BLE_CONN_CFG_TAG, &ram_start);
APP_ERROR_CHECK(err_code);

// Enable BLE stack.
err_code = nrf_sdh_ble_enable(&ram_start);
APP_ERROR_CHECK(err_code);

// Register a handler for BLE events.
NRF_SDH_BLE_OBSERVER(m_ble_observer, APP_BLE_OBSERVER_PRIO, ble_evt_handler, NULL);
}

And also i already have configured the NRF_SDH_SOC_OBSERVER in the same way of the example:

static void mesh_soc_evt_handler(uint32_t evt_id, void * p_context)
{
nrf_mesh_on_sd_evt(evt_id);
}

NRF_SDH_SOC_OBSERVER(m_mesh_soc_observer, MESH_SOC_OBSERVER_PRIO, mesh_soc_evt_handler, NULL);

If i place a braskpoint in the nrf_mesh_on_sd_evt(evt_id); call, it is correctly triggered.

There is a however difference in the mesh configuraton parameters:

mesh_stack_init_params_t init_params =
{
//.core.irq_priority = NRF_MESH_IRQ_PRIORITY_LOWEST,
.core.irq_priority = NRF_MESH_IRQ_PRIORITY_THREAD,
.core.lfclksrc = DEV_BOARD_LF_CLK_CFG,
.core.p_uuid = NULL,
.models.models_init_cb = models_init_cb,
.models.config_server_cb = config_server_evt_cb
};

I changed the the core.irq_priority from NRF_MESH_IRQ_PRIORITY_LOWEST to NRF_MESH_IRQ_PRIORITY_THREAD to be able to process mesh events from the application main cycle calling the function bearer_event_handler().

Is it possible that this modificatio is the cause of the problem? I will try to return to the original configuration but it's not easy because various application tasks are syncronized from the main cycle.

[AHaug]

Gianluca said:

I changed the the core.irq_priority from NRF_MESH_IRQ_PRIORITY_LOWEST to NRF_MESH_IRQ_PRIORITY_THREAD to be able to process mesh events from the application main cycle calling the function bearer_event_handler().

Is it possible that this modificatio is the cause of the problem? I will try to return to the original configuration but it's not easy because various application tasks are syncronized from the main cycle.

This could be the case. I've brought this (and the other comments you mention) up in the discussion I have going with the Mesh team and I will let you know if we land on something more constructive. In the meanwhile let me know if changing the core.irq prio changes anything in what you're able to observe

Kind regards,
Andreas

[AHaug]

Do you call `app_sched_execute()` as explained here: infocenter.nordicsemi.com/.../md_doc_user_guide_mesh_interrupt_priorities.html ?

[Gianluca]

Hi Andreas, i have modified the firmware following all the indications in the link you passed me. The BLE advertising and NUS connectivity are still working, the BLE mesh communication is still working too. Unfortunately the remote provisioning functionality is still not working. I tried to keep active only the remote provisioning model just to avoid conflicts with out application custom models without success: the unprovisioned server still doesn't transmit the unprovisioned device beacon packets.

Just to be precise:

to avoid an application crash in the main cycle, i need to call the following  macro two times

APP_SCHED_INIT(APP_TIMER_SCHED_EVENT_DATA_SIZE, SCHED_QUEUE_SIZE);

The first one at the beginning of the main cycle just before the call of the function

app_timer_init()

The second time just before the main loop and after the initialization of the stack and the BLE and mesh functionalities.

Without this trick, i had a system reboot inside the function

void app_sched_execute(void)

during the call to event_handler(p_event_data, event_data_size);

It seems tha the event handler function pointer is not initialized correctly.

Tanks again and have a nice day,

Gianluca.

[AHaug]

Hi,

From what we can see in our tests we only call APP_SCHED_INIT() once after all other initialization that you mention (i.e after app_timer_init(), the initialization of the stack and the BLE and mesh functionalities), so I think that your fix of calling the macro twice covers over something else that might be the issue.

From what we see in components/libraries/scheduler/app_scheduler.c of nRF5 SDK, the app_sched_event_put() function doesn't check if user passed NULL as the callback pointer and then app_sched_execute() just dereferences whatever it has in the queue. We would like to know what happens there in your application, so if you're able to, could you check what function calls app_sched_event_put() with NULL as a handler or to check what event is pulled out of the queue in app_sched_execute() with NULL pointer as handler? GDB should work here.

Kind regards,
Andreas

[Gianluca]

Hi Andreas,

thank you, after some days of attempt, i finally succeeded!

The double call to the macro APP_SCHED_INIT was due to the need of configure the FDS system (Flash Data Storage) to read the device configuration as soon as possible after the boot.
I set up a state machine on the main function to correctly manage the configuration steps founding the correct sequence to enable BLE adv, mesh and remote provisioning advertisings. Now on the snivver, i see the unprovisioned device beacon packets and using the remote provisioning client example, the provisioning works. Now i have to add the configuration client/server functionality to complete the provisioning phase. Can you suggest me some examples where this funcionality is implemented?

Have a nice day,

Gianluca.

[AHaug]

Hi,

Gianluca said:

thank you, after some days of attempt, i finally succeeded!

Glad to hear it!

Gianluca said:

Now i have to add the configuration client/server functionality to complete the provisioning phase. Can you suggest me some examples where this funcionality is implemented?

As far as I know every sample should have the configuration client/server implemented, so I would recommend to pick either the light switch/bulb or sensor server/client samples from the sample list and to follow the documentation from : infocenter.nordicsemi.com/.../md_examples_README.html

Let me know if this is enough to answer your latest question!

Kind regards,
Andreas