Problem with provisioning after reset

Question

Hi

We are able to provision several mesh-servers.

The log on the RTT-Viewer of the client looks normal:

0> <t:    915394>, mesh.c, 178, Local provisioning link established
0> <t:    916961>, mesh.c, 237, Using static authentication
0> <t:    928785>, mesh.c, 248, Static authentication data provided
0> <t:    939937>, mesh.c, 193, Provisioning complete! Added 01F4 as handle 1
0> <t:    940270>, provisioner.c, 122, Getting composition data
0> <t:    942757>, provisioner.c, 332, Composition data: 00590000000000200001000000030100000200040059000000
0> <t:    942761>, provisioner.c, 130, Adding appkey
0> <t:    943853>, mesh.c, 182, Local provisioning link closed
0> <t:    946897>, provisioner.c, 139, Binding appkey to the Health model
0> <t:    947742>, provisioner.c, 151, Binding appkey to the Simple message model
0> <t:    949061>, provisioner.c, 176, Setting publication address for the health server to 0x0001
0> <t:    952639>, provisioner.c, 198, Setting publication address for the message server to 0x0001
0> <t:    957205>, provisioner.c, 207, Adding subscription
0> <t:    958533>, mesh.c, 548, Configuration of device 0 successful
0> <t:    958537>, mesh.c, 558, provisioner_config_successful_cb

When we reset (restart) the client(provisioner) board and then try to provision further servers we get

a Mesh assert.

0> <t:    390869>, mesh.c, 178, Local provisioning link established
0> <t:    392374>, mesh.c, 237, Using static authentication
0> <t:    403809>, mesh.c, 248, Static authentication data provided
0> <t:    415206>, mesh.c, 193, Provisioning complete! Added 01F5 as handle 2
0> <t:    415540>, provisioner.c, 122, Getting composition data
0> <t:    419283>, mesh.c, 182, Local provisioning link closed
0> <t:    430889>, provisioner.c, 332, Composition data: 00590000000000200001000000030100000200040059000000
0> <t:    430892>, provisioner.c, 130, Adding appkey
0> <t:    434469>, provisioner.c, 139, Binding appkey to the Health model
0> <t:    436060>, app_error_weak.c, 95, Mesh assert at 0x0003C562 (:0)

Addr2line leads to line 347 of provisioner.c:

else if (p_event->opcode == CONFIG_OPCODE_MODEL_APP_STATUS &&
         m_prov_state == PROV_STATE_CONFIG_APPKEY_BIND_HEALTH)
{
>>> NRF_MESH_ASSERT(p_event->p_msg->app_status.status == ACCESS_STATUS_SUCCESS);
      m_prov_state = PROV_STATE_CONFIG_APPKEY_BIND_ONOFF;
      do_config_step();
}

p_event->p_msg->app_status.status is ACCESS_STATUS_INVALID_ADDRESS instead of ACCESS_STATUS_SUCCESS

We are using Mesh_SDK 2.0.1 and nRF5_SDK_15.0.0 / Softdevice 6.0.0.

Question: What could lead to this invalid address state?.

Kind regards

Gerry

tesc · Accepted Answer

Hi, 
 It should not be a problem in and of itself that the example is ported, but it means now I better know the context of what you are doing. 
 It seems to be related to the addresses stored by the device state manager (dsm). I would guess that the error of NRF_ERROR_INVALID_ADDR originated in packet_tx() in access.c, because of a mismatch between the addresses stored by the dsm and the index information stored in the model. A bit hard to tell for sure, of course, since the project is ported and things may have changed throughout the SDK revisions. 
 In any case, while the dsm automatically stores changes to flash, this is not necessarily done for the data used by the access module (in access.c). Hence the function access_flash_config_store(). Further, if at the point of reset, either the dsm or access has stored data to flash, but the other has not, the data will be in an inconsistent state comparable to a dangling pointer, leading to the kind of error that you experience. 
 I am afraid these things are complex, and I do not have enough time to properly get to the bottom of it before the holidays, but I know that this is an area where our mesh team want to improve the SDK. From what I understand they have done some work on that for later releases. It may even be that those improvements are what effectively renders the ported example prone to inconsistency if resetting the (combined client and) provisioner halfway through the provisioning steps. 
 Hopefully I have at least provided some pointers to where to look. If anything is unclear, let me know and I will try to elaborate. 
 Regards, Terje

Problem with provisioning after reset

Top Replies