Problem with provisioning after reset

RE: Problem with provisioning after reset

Gerry — Thu, 20 Dec 2018 09:36:11 GMT

Hi,

thanks for your detailed estimation on that problem. We were searching and debugging for quite a long time on this, but the reason seems to be deeper in the SDK, where we don't really understand the mechanisms. Would be good, if you could take a look at it from your professional perspective after the holidays. Might be a good idea to make this case private, so we can share our client/provisioner code with you.

Regards

Gerry

RE: Problem with provisioning after reset

tesc — Fri, 14 Dec 2018 17:31:29 GMT

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

RE: Problem with provisioning after reset

Gerry — Wed, 12 Dec 2018 15:36:59 GMT

Hi,

yes, we started with mesh v1.0.1 and the updated to Mesh 2.0.1. Is there a Problem with that? We didn't make changes tp provisioner.c and the application is runnig fine accept the issue above.

Regards

Gerry

RE: Problem with provisioning after reset

tesc — Wed, 12 Dec 2018 15:26:48 GMT

Hi,

I found this file now in the combined client+provisioner example from nRF5 SDK for Mesh v1.0.1. Have you ported this project over to nRF5 SDK for Mesh v2.0.1, from that older version?

Regards,
Terje

RE: Problem with provisioning after reset

Gerry — Tue, 11 Dec 2018 13:47:01 GMT

Hi,

attached the file provisioner.c. The nRF5 SDK Version was correct.

By reset (restart) I mean pressing the reset button on the nRF52840 DK

regards

Gerry

devzone.nordicsemi.com/.../provisioner.c

RE: Problem with provisioning after reset

tesc — Tue, 11 Dec 2018 12:02:30 GMT

Hi,

I was not able to find provisioner.c, nor the line with the assert, in nRF5 SDK for Mesh v2.0.1... Did you mean provisioning.c, and can you recheck and confirm the nRF5 SDK for Mesh version?

Crashing is "normal behavior" if you flash the mesh application without erasing flash first. This is because anything in the flash area designated for storing provisioning data, device status, etc. may be interpreted wrongly leading to undefined behavior or error in parsing the data.

How are you resetting the client/provisioner board, what are the steps for reproducing?

Regards,
Terje