This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Bluetooth Mesh Light Switch Example Provisioner DFU implementation fail.

Hello 

I am working on a project based on the Mesh SDK 2.0.1 light_switch example. The system is using SD 6.0.0 and PCA10040 boards. DFU is successfully implemented on the servers(which are running as dual client/servers) with no serial support. 

The last stage of implementing DFU in the project is setting up the provisioner to have serial DFU support. The necessary code is implemented from the DFU example in the same way as on the servers. The only difference being NRF_MESH_SERIAL_SUPPORT 1 is defined instead of 0

As the provisioner already has a mesh event handler, the switch case is extended to include DFU.

2 problems arose when trying to run the code on the provisioner.

1) When enabling serial on the provisioner, and trying to provision a server the provisioner seems to be going into an infinite loop when trying to configure health models on the server. 

2) When flashing the provisioner with the serial bootloader and device page, it goes into mesh assert. I think the problem lies in usage of the flash but I have not been able to find the parameters for where in the flash storage a provisioner stores it's persistent data.

Any suggestions are welcome.

Regards,

Martin

  • Hi Martin,

    The first issue is caused by a limitation in the serial driver in the mesh, that makes it lock up when the host doesn't pop its outgoing packets. See the note in step 8 of the DFU quickstart guide. Only enable the serial module for devices that are actively communicating with the host. You can also remove the call to nrf_mesh_evt_handler_add in serial_handler_mesh_init() in serial_handler_mesh.c, if you only want the DFU module to push events to serial.

    I believe the second problem happens because you've got other stuff in your flash manager regions. If you're adding your own flash manager before this mesh_stack_init call, that might be it, otherwise, check your flash configuration, and see if your app, bootloader or softdevice is using the same flash page for something else.

  • This solved it. By moving the flash area used by dsm by defining DSM_FLASH_AREA_LOCATION in device_state_manager.c and setting it outside of the area of the bootloader the assert problem dissappeared. The serial problem was solved by removing the call to nrf_mesh_evt_handler_add. It's currently in test but it looks promising.

    Thank you!

Related