Mesh Peripheral can no longer be provisioned, does not show up in scanning.

[Terry2]

We have developed a system that is comprised on a BLE mesh peripheral (proxy) sensor, and multiple mesh node sensors all using the 52833. The proxy node connects to an Android app to configure, control and use the data from the sensors over a NUS connection. We now have 2 proxy (hub) nodes that can no longer be provisioned after their firmware had been updated using DFU. The devices do not show up during scanning for unprovisioned devices in both our custom Android App as well as the nRF Mesh App. 

I also have a 3rd proxy node that shows up during scanning but the provisioning quits very shortly after and does not complete. A complete flash erase and re program does not clear this issue. Does anyone have any ideas what happened to these mesh proxy devices and how to recover them? We have been working with these mesh devices for months without issue but have only recently started using DFU to update the targets. Now we have 3 unusable devices.

[Hung Bui]

Hi Terry, 

Have you tested the DFU application in your lab, did it work has the device managed to start after DFU update ? 
What change has been made to the new application ? Extra care must be taken if you have changed flash data (including the provisioning data). 

Could you give more information about the SDK you used ? 

A complete flash erase and re program does not clear this issue.

Could you tell how did you do a complete flash erase ? There could be a chance that user data has not been cleared and that can confuse the flash manager and cause an assert. 

[Terry2]

Yes we tested in lab before the release but not many cycles. We are using nRF Connect SDK v2.3.0 with VS Code. I found the issue with my third device that would not complete the provisioning. In the nRF Connect for mobile app I clicked on 'Delete bond information" and now the device provisions properly. Before this I tried the nRF Connect for Desktop - Programmer to erase all flash but since we are running on external flash this likely does not erase provisioning information. I will have the client install nRF Connect for mobile and see if removing the bond information solves their problem. UPDATE: this did not help.

UPDATE: We added a button press sequence on the target to trigger the device to remove the provisioning by calling bt_mesh_cdb_clear() and bt_mesh_reset(). This reset the device so it could then be provisioned again. It appears the un-provisioning step failed somewhere in that process but the App said it completed successfully. I'm not sure yet what steps are taken in the App to un-provision a device but this is where our focus now lies to understand and fix this issue from happening again. Any clarity on that process would be appreciated.

[Hung Bui]

Hi Terry, 

Could you please give more information about the DFU process in your system ? Is it Mesh DFU or BLE DFU that you would do one by one via the phone ? 
The two proxy/hub that got the issue, have you tried to erase and reflash them ? 
My suspicious is that there is something wrong with the data stored and it cause the device to crash, not able to do any advertising. Do you have any log from the device ? 

Have you managed to reproduce the issue in-house ? 

After bt_mesh_reset() do you reset the device immediately or you choose to let the device start advertising as unprovided node ? 

[Terry2]

We are using BLE DFU one by one using tablet/phone. Unfortunately the devices where this problem showed up are at the clients location so we were not able to capture logs from them or try to reflash them using the debugger. After the bt_mesh_reset(), yes we did a manual reboot. The devices then started advertising and were able to be provisioned again. After many DFU cycles we were not able to reproduce the issue in our office. We are using external flash and I verified the provision information is still stored after a DFU cycle. Our latest assumption is that the device did not un-provision successfully which likely caused this issue. Can you please outline the steps the mobile takes to un-provision/delete a mesh device? Are there many calls in Android to complete this process and why do you think this might have failed?

[Hung Bui]

Hi Terry, 
You can look at the app source code to find that it simply send one single CONFIG_NODE_RESET opcode to reset the node: 
https://github.com/NordicSemiconductor/Android-nRF-Mesh-Library/blob/main/app/src/main/java/no/nordicsemi/android/nrfmesh/node/NodeConfigurationActivity.java#L271

Here is what inside ConfigNodeReset.java

What I concern of is if you have wait untilbt_mesh_reset() has finished the flash operation before you reset. 
If you look at the code of the new mesh DFU sample you can find this: 
https://github.com/nrfconnect/sdk-nrf/blob/main/samples/bluetooth/mesh/dfu/common/src/dfu_target.c#L205

It wait for  1ms before it execute the reset command. 
Could you tell us the sequence on how you do DFU and reset the node ?

I think you may need to recall the defect unit and check the log if any or step into the code to see where it crashed. 

[Terry2]

Yes we manually reset the device after doing the bt_mesh_reset(). The 2 devices in the field are now running again after this and could be provisioned so we can close this discussion now.