Automatic provisioning for fast test fails.

[alebldn]

Dear fellow developers,

We're developing a test network for our bluetooth mesh devices where the final step is automatic provisioning for fast configuration (of course, limited to testing environments). In order to do so, we're studying the bt mesh demo sample. Our project is perfectly similar to it as it contains a configuration client that is supposed to configure the node once provisioned so we can seamlessly take the sample as example for this ticket.

Problem is, using bt_mesh_provision to provision the node using hardcoded keys raises some errors.

1. MPU Fault when using CONFIG_SETTINGS=y. As shown in the image below, building and running the sample for DK 52840 produces a MPU fault that can be bypassed by setting CONFIG_SETTINGS=n in prj.cfg. (We're not experiencing this error in the project so I'll skip it)
   
   
   
2. After setting CONFIG_SETTINGS to n, the MPU fault disappears. Apparently the node manages to provision itself and to call the configure() function as the provisioning phase is over. This configure function uses the configuration client's functions to add a NetKey to the node, add a AppKey to the node, bind the AppKey to a health model and to a vendor model. Unfortunately, this does not work correctly as each of the functions return a -116 (ETIMEDOUT) error (as shown below).
   

I've been working with the 2.5.1 toolchain up until yesterday but the pictures were taken using the latest one, 2.5.2.

The only changes I've made in the project are:

1. Addition of printk functions as shown in the pic below to showcase the values of ret and status on different operations (as I'm having troubles debugging).
   
2. Modifications of prj.conf file so enable logging and disable the settings subsystem.
   

A trace of the error (in one of the 4 functions) is:

bt_mesh_cfg_cli_app_key_add

'-> bt_mesh_msg_ackd_send

'-> bt_mesh_msg_ack_ctx_wait

How would you advise me to solve this problem?

Thanks for your kind attention, I hope to hear back from you guys soon.

Ale

[Hung Bui]

Hi Alessandro, 

It's most likely due to stack overflow that you are seeing the issue. 
Could you try to test with the mesh_demo sample and change 

CONFIG_MAIN_STACK_SIZE=1024

And check if you still see the problem ?

In my test here with v2.5.2 the device get reset immediately after booting and I have to increase the main stack size to 1024 to make it works. 

[alebldn]

Dear Hung Bui, thanks for the quick reply. You're right indeed, it solves the first problem.

Unfortunately, though, it does not solve the second one where configuration client messages wait for an ack that is not coming (therefore raises a  -116 (ETIMEDOUT) error).

[Hung Bui]

Hello, 
I would suggest to try testing on unmodified mesh_demo sample. 
I did a test here and it worked fine. 

If it doesn't you may want to step into the code and check which function return -116. Normally when the message is for the node itself, it will not be transmitted to the radio and shouldn't return TIMEOUT.

[alebldn]

You're technically right. The thing is that settings the status param != NULL to receive a confirmation from the cfg srv makes it timeout.

Of course, in the main project I already tried to set the status parameter to NULL but, despite the configuration client functions returning 0 on spot when adding a key, binding this key to a model produces the -116 error.

I guess you can verify this yourself using the same mesh demo. Just substitute the following code in the configuration function.

int status = 0;

/* Add Application Key */

printk("%d\n", bt_mesh_cfg_cli_app_key_add(net_idx, addr, net_idx, app_idx, app_key, &status));

/* Bind to vendor model */

printk("%d\n", bt_mesh_cfg_cli_mod_app_bind_vnd(net_idx, addr, addr, app_idx, MOD_LF, BT_COMP_ID_LF, &status));

/* Bind to Health model */

printk("%d\n", bt_mesh_cfg_cli_mod_app_bind(net_idx, addr, addr, app_idx, BT_MESH_MODEL_ID_HEALTH_SRV,

&status));

/* Add model subscription */

printk("%d\n", bt_mesh_cfg_cli_mod_sub_add_vnd(net_idx, addr, addr, GROUP_ADDR, MOD_LF, BT_COMP_ID_LF,

&status));