Mesh functionality in Bootloader

[tmwinjy]

Hello,

I am currently attempting to include mesh functionality in a bootloader so as to have it do DFU over mesh without the serial port. I keep getting errors when trying to initialize the mesh (an ASSERTION ERROR in the entry_validation() function). Could you please explain to me what the bare minimum requirements are to initialize the mesh stack.

I have already added all mesh files and adjusted the linker to fit the bootloader in the flash space. I just want to know exactly what it would take to successfully initialize the mesh.

Context:

3 Nordic Thingy52s

nRF SDK for mesh v2.2.0

nRF SDK 15.0.0 softdevice (v6.0.0)

Base bootloader code from nRF15s secure_bootloader in the dfu example.

[Hung Bui]

Hi,

Could you explain what exactly you want to achieve ? How do your devices operate ? 

Do you plan to include the mesh stack for just doing DFU not for normal operation ? Note that for a mesh network to operate, you would need to set all your devices to bootloader/mesh mode. How do you convert the data you transfer in Mesh to the image for the bootloader to replace the application image ? 

Be aware that the mesh stack would occupies roughly 100kB of the flash. 

[tmwinjy]

I hope to create a bootloader that is able to receive an OTA DFU and update all nodes in the mesh network (similar to what is done by the serial DFU example in the mesh SDK except the initial node receives the DFU zip file through BLE instead of serial port). The mesh stack in the bootloader would just be for doing DFU.

I planned on sending the image packets to the other nodes as they were being updated on the initial node (every time it begins writing a page it sends it to the other nodes to write and only requests the next page upon confirmation from the other mesh nodes).

Currently space  is not a major concern as I want to test if this OTA DFU mesh can be done. I am however failing to initialize the mesh on any individual device.

[Hung Bui]

OK, so it's actually the opposite. You have a mesh network and you want to do DFU but to transfer the initial image via BLE instead of via Serial. 

We don't have an example for that, but I would suggest you go from the original Mesh bootloader and add the BLE functionality to it to receive image instead of via serial. It's easier than modify the BLE bootloader to add mesh in, in my opinion. 

Due to limited resource, I'm afraid that beside the documentation, and the source code, we can't really make an example code for you at this moment. 

[tmwinjy]

Thank you for the answer. I am wondering what is the bare minimum mesh_init code required in order to add ble mesh stack to the existing bootloader as per your suggestion

[Hung Bui]

Hi, maybe you read me wrong. My suggestion is to use the Mesh bootloader and add BLE into that. 

To begin with, I would suggest to base your application on ble_app_uart_coexist. Add the support for mesh DFU into that example (refer to dfu example in mesh SDK) then use the UART profile (NUS) to receive image. 

[tmwinjy]

Hi. Thank you for the clarification. Started using the sdk_app_uart_coexist as my base and it does have a working mesh initializer and all. I will add the DFU functionality and report my findings.

On occasion, I receive the error code NRF_ERROR_NO_MEM=4. It resolves itself upon restart but I was wondering why this was?

[Hung Bui]

You need to point to a function that throws error NO_MEM so we can check what could the issue be. 

[tmwinjy]

It starts as an event error in uarte_irq_handler() in nrfx_uarte.c It later goes on to report an APP_UART_FIFO_ERROR in main.c. It finally reports NO_MEM by app_handler_bare by the last call. I made a workaround for the FIFO error but then it reports an  APP_UART_COMMUNICATION_ERROR instead. This resolves after a restart but occurs every time I try debugging with the JLink.