After Unpromising (Reset Node) the node is not able to discover for further provisioning.

[ramachandra]

Hi,

   We are using nRF52840 chipset with SDK 15.0.0  with Mesh implemetation. 

1. We are provisioning the mesh node using the nRF mesh APP.

2. Then we are resetting the node using same nRF mesh APP.

3. Sometimes above works and we are able to scan/see the node in unprovision list  of mesh APP. 

4. But sometime when we reset (unprovision) the node it is not coming back in unprovision list neither we are able to scan/see  it anymore.which is almost dead state for us because we are no longer able to see and connect it.

This has become show stopper for us because even after power cycle we are not able to discover it. 

Waiting for your immediate resolution and support.

Regards,

Ram

[Robin M Saltnes]

Hi Ram, 

Depending on the firmware you're running on the nodes it may not have been designed to put the nodes back into "provisioning mode" after a reset in the app. The easiest way to get the nodes back this state would simply be to re-upload the firmware to the nodes.

The alternative would be to rewrite the firmware code to enable a function where the nodes goes back into "provisioning mode" after being reset in the app. 

Best regards, 

Robin

[ramachandra]

Hi Robin,

  As mentioned in my previous message in point 3 we are having the supporting firmware to unprovision the node and it is working.

As mentioned in point 4 the actual problem is sometime the unprovision fails  (say out of 10 tries 2 times fail) after that the node is not visible in either provision or unprovision list.

Even when we power cycle the module it is not even visible in nRF connect APP. It means the BLE chip is DEAD and no more it is accessible from any BLE APP. 

Observation:

    During unprovison we have the function call mesh_stack_config_clear() to clear the mesh information, during the execution of this function we observe that the BLE chip is resetting because of which the unprovision might be not happening properly.

Please let us know how we can handle it.

Regards,

Ram

[ramachandra]

Hi Robin,

   Additional to the above information please find the snippet where the BLE chip get reset when we try to close the app in which the provisioning is done.

Regards,

Ram

[Robin M Saltnes]

Hi Ram,  

Please see how our mesh example programs handles unprovisioning of nodes by calling the mesh_stack_config_clear() function below.

static void node_reset(void)
{
    __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "----- Node reset  -----\n");
    hal_led_blink_ms(LEDS_MASK, LED_BLINK_INTERVAL_MS, LED_BLINK_CNT_RESET);
    /* This function may return if there are ongoing flash operations. */
    mesh_stack_device_reset();
}

You are free to copy this or use it as an inspiration for your own projects. 

Best regards, 

Robin

[ramachandra]

Hi Robin,

   As specified i  tried to use the function node_reset() to unprovison the device from the mesh network, But looks like the device is not getting unprovisioned from the network, In nrf Mesh APP it is showing in the provisioned list.

Function Call:

node_reset()

Regards,

Ram

  

[Hung Bui]

Hi Ram, 

I'm handling the case from Robin.

I suspect that you have reset the chip before you finished erasing the flash. Time to erase one page can take up to 89.7ms. 

Using a delay after calling mesh_stack_config_clear() may not be the best option. 

If you have a look at the apply_reset() function inside config_server.c you can find that we need to check for flash_manager_is_stable() before we forward the event to the application for a reset. And there we also check for flash stable before we trigger the reset. 

I'm not sure why you need to write your own UnprovisionMeshNode() function. Why wouldn't you use our already made function to handle node reset handle_node_reset() when receive CONFIG_OPCODE_NODE_RESET ?

Which Mesh SDK are you using ? Have you tried to use our example for example lightswitch server and trigger a node reset from the app ? Which issue do you have when doing that ? 
Please also try to test on fresh (and newer if possible) SDK just to make sure there wasn't any modification that can cause an issue. 

[ramachandra]

Hi Hung,

   Thanks for providing the inputs and supporting us.

  As informed i tried to use the function apply_reset(), but this is called from the callback function mesh_event_cb(), how do i trigger this callback function intern which triggers the apply_reset() function.

  Actually in our current code the Mesh reset  is happening randomly ( say out of 10 tries 6 tries it reset the node another 4 it fails). 

In failure case it is observed that the BLE chip get reset automatically before be execute the reset command( force reset).

Even we are not able to have the calll stack information in the bedugging mode to find out the reason for failure.

Currently we are using the proxy Mesh SDK, Please let me know is there any way to identity the version number of Mesh APP because it is old code and i didnt get the Mesh SDK with name proxy Mesh SDK in nordic official release.

 

 

[Hung Bui]

Hi Ramachandra, 

I don't recognize the "nrf52-mesh-proxy-server" folder. What's inside that folder ? Could you step in the bin\softdevices folder and take a screenshot? 
I strongly suggest you to migrate to our latest Mesh SDK which is version 4.2 

We noticed that you are having multiple cases with us and on your other cases your mesh doesn't work very reliably. I would suggest that you test using our latest SDK and firmware on your board to check if you see the same issue. This is to verify that the issue was not from your hardware but maybe from  your firmware. 

In our lightswitch server example we allow pressing button 4 to reset the node,  you can try to do the same on your firmware to check if it can reset the node (without sending mesh packet to reset) this way you maybe able to debug it easier. Note that to debug you need to clear the code optimization in the compiler. 

[ramachandra]

Hi Hung,

  Please find the details below.

  The bin\softdevices contains the softdevice images. We are currently the BLE chipset nRF52840 and s140 softdevices ehile programming. 

  

  

I will try to test the suggested SDK on our hardware and let you know how it behaves.

Regards,

Ram

[Hung Bui]

Hi Ram, 

It seems that you are using pretty old SDK, most likely SDK v2.2.0. 
I suggest you to move to latest SDK.

If it's not possible you may need to test with our example and check if you get the same issue or not.  Note that when you debug you need to set optimization level to 0 and debug level to 3. 

[ramachandra]

Hi Hung,

   Sure we will try with the new Mesh SDK version 4.2 and check it out once.

   But does this SDk support for configuring both Generic On OFF Server and Generic On Off Client model in same binary image as shown in the below snippet.

  Because i remember before using the proxy sdk( which we are using currently) we use to have two separate binary images one for configuring the Generic On OFF Server and one for Generic On Off Client( We use to get only 1 option under Element)

Please suggest if anything i am missing.

Regards,

Ram

  

[ramachandra]

Hi Hung,

    We have observed the issue that the Exception is getting generated when the BLE APP which is connected to the BLE chip is is closed all of a sudden, It is generating the exception, Please find the snippet below for the call stack and the error

Regards,

Ram