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

[alebldn]

Hi Hung Bui,

A quick update: unfortunately, there's still something that is unclear to me about how the underlying code works. Even setting the add_app_key to be asynchronous and non-blocking doesn't solve the issue.

Unfortunately, the project I'm working on is protected by an NDA so I can't really disclose more than I already did with you. While I managed to make the thread approach work on the sample, I still had some troubles implementing it in the project.

BUT. But I was able to make the whole thing work anyway thanks to your suggestions:

• Set every single call to the cfg client to be asynchronous non-blocking by seting status parameter to NULL.
• Implemented the semaphore logic so to configure the node only after the bt_ready function has finished.

At this point, I would get two errors:

• <err> bt_mesh_transport: No multi-segment message context available
• <wrn> bt_mesh_net: Unable to allocate loopback.
  <err> bt_mesh_cfg_srv_ Unable to send App Key Status response.

I managed to solve these errors by setting in the prj.conf file respectively:

• CONFIG_BT_MESH_TX_SEG_MSG_COUNT=8
  CONFIG_BT_MESH_RX_SEG_MSG_COUNT=8
• CONFIG_BT_MESH_LOOPBACK_BUFS=8

Now everything does work as intended. Thank you for your great effort and help, it's always a pleasure to talk to you. Have a great day,

Ale

[Hung Bui]

Hi Ale, 
I'm glad that you now have a working prototype. Best of luck with the further development of the project.