This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

nRF5 SDK for Mesh: How to reset a Bluetooth Mesh node?

Dear Nordic experts,
 
This short code snippet is supposed to reset (unprovision) a Bluetooth Mesh node and reboot it (nRF5 SDK for Mesh 5.0.0):
 

void node_reset(void)
{
    __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, " >>>>> Resetting node <<<<< \n");
    if (mesh_stack_is_device_provisioned()) {
        mesh_stack_config_clear();   
        mesh_stack_device_reset();
    }
 
    schedule_reboot();  // just waits for 2 seconds before calling sd_nvic_SystemReset(); to reboot the node.
} 

 
node_reset() is called at the main() loop once an input pin is set. At the time it is called, the (custom/vendor) model is still operating. The problem is, that mesh_stack_config_clear() ends up in app_error_fault_handler().  
 
The following is printed at the debug terminal in SES:
 
<t:    2006463>, main.c,  252,  >>>>> Resetting node <<<<<  
<t:    2006553>, main.c,  213, Mesh event: NRF_MESH_EVT_CONFIG_STABLE
<t:    2006556>, main.c,  217, Mesh event: NRF_MESH_EVT_FLASH_STABLE
<t:    2006559>, main.c,  217, Mesh event: NRF_MESH_EVT_FLASH_STABLE
<t:    2006650>, main.c,  213, Mesh event: NRF_MESH_EVT_CONFIG_STABLE
<t:    2006653>, main.c,  217, Mesh event: NRF_MESH_EVT_FLASH_STABLE
<t:    2006656>, main.c,  217, Mesh event: NRF_MESH_EVT_FLASH_STABLE
<t:    2006747>, main.c,  213, Mesh event: NRF_MESH_EVT_CONFIG_STABLE
<t:    2006750>, main.c,  217, Mesh event: NRF_MESH_EVT_FLASH_STABLE
<t:    2006753>, main.c,  217, Mesh event: NRF_MESH_EVT_FLASH_STABLE
<t:    2006844>, main.c,  213, Mesh event: NRF_MESH_EVT_CONFIG_STABLE
<t:    2006847>, main.c,  217, Mesh event: NRF_MESH_EVT_FLASH_STABLE
<t:    2006850>, main.c,  217, Mesh event: NRF_MESH_EVT_FLASH_STABLE
<t:    2006869>, app_error_weak.c,  105, Mesh assert at 0x0002E65E (:0) 

 
And the stacktrace looks like this:
 
app_error_fault_handler()
mesh_assertion_handler()
backend_evt_handler()
write_complete_cb()
process_action_queue()
send_end_events()
bearer_event_handler()
bearer_event_flag_set()
mesh_config_backend_record_write()
dirty_entries_process()
mesh_config_entry_set()
seqnum_block_allocate()
mesh_stack_config_clear()
node_reset()
main() 

 
The questions now are:  
What's causing this issue? Or: How do you reset/unprovision and reboot a mesh node in nRF5 SDK for Mesh 5.0.0?  
 
Your help is very much appreciated,
Thank you,
Michael.

  • It seems the API has changed from mesh_stack_config_clear(); to mesh_config_clear();
    Kinda strange, the above code is working in the firmware version from about a year ago.

  • Hi Mike, 

    I would suggest mesh_stack_config_clear() instead of calling mesh_config_clear() 

    Can you reproduce the issue using one of our example ? For example the light switch server ? We do have the functionality that if you press button 4 it will clear the setting and reset the node. Please check the node_reset() function in main.c 

    Also, as I can see in the code how the config server handle node reset command from the client (check handle_node_reset() ). It will go through the following stages: 
    typedef enum
    {
    NODE_RESET_IDLE,
    NODE_RESET_PENDING,
    #if MESH_FEATURE_GATT_PROXY_ENABLED
    NODE_RESET_PENDING_PROXY,
    #endif /* MESH_FEATURE_GATT_PROXY_ENABLED */
    NODE_RESET_FLASHING,
    } node_reset_state_t;

    So if the flash module is busy it will stay in pending state(NODE_RESET_FLASHING) and wait for NRF_MESH_EVT_FLASH_STABLE event before it continue to the node reset process. 

  • Hi Hung,
     
    Thanks for your help. Just a quick question:  
    Imagine a simple custom node, containing a single element with a single instance of a proprietary/vendor model plus a configuration server and health server instance.
     
    Whats the recommend api to store a few hundred bytes of model related data in flash?
    model_config_file_xxx(), mesh_config_entry_xxx() flesh_manager_xxx()? Or something else?
     
    Are the model_config_file_xxx() api calls needed for vendor (i.e. non standard/generic) models? Would it be safe to omit those calls?  (please note: config and health server are running as well.)
    Right now, I'm using the mesh_config_entry_xxx() api - which works quite well, except the previously mention fault triggered by mesh_stack_config_clear(), which makes me think that I'm most likely using the wrong api for the job...

    Any clarification is welcome,
    Thank you,
    Michael.


     

  • Hi Michael, 
    The recommended way of storing data in mesh is to use your own file and entries in the file (mesh_config_entry_xxx). I would suggest to have a look at the enocean example where we store some custom data in a separated file. 

    Could you try to reproduce the issue with one of our example so we can test here ? 

  • Hi Hung,

    Thanks for the fast reply! I'm using mesh_config_entry_xxx() api's right now, but they are causing some issues - especially when deleting the data during reset/unprovisioning.

    Could you try to reproduce the issue with one of our example so we can test here ? 

    Sure, but the problem is a little more complicated: The way it looks right now, the issue happens if the node is provisioned, but not fully set up. For example when the (Android) app starts provisioning, but the connection gets lost before an App key is assigned. Trying to reset the node by calling mesh_stack_config_clear() causes the firmware to get trapped in app_error_fault_handler() - basically brick-ing the device...

    I need some way to recover from it. Do you have any ideas how to prevent app_error_fault_handler() from making the node inaccessible/unresponsive?

Related