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.

[Hung Bui]

Please check what exactly in uarte_irq_handler() give the error ? 

[tmwinjy]

static void uarte_irq_handler(NRF_UARTE_Type *        p_uarte,
                              uarte_control_block_t * p_cb)
{
    if (nrf_uarte_event_check(p_uarte, NRF_UARTE_EVENT_ERROR))
    {
        nrfx_uarte_event_t event;

        nrf_uarte_event_clear(p_uarte, NRF_UARTE_EVENT_ERROR);

        event.type                   = NRFX_UARTE_EVT_ERROR;
        event.data.error.error_mask  = nrf_uarte_errorsrc_get_and_clear(p_uarte);
        event.data.error.rxtx.bytes  = nrf_uarte_rx_amount_get(p_uarte);
        event.data.error.rxtx.p_data = p_cb->p_rx_buffer;

        // Abort transfer.
        p_cb->rx_buffer_length = 0;
        p_cb->rx_secondary_buffer_length = 0;

        p_cb->handler(&event, p_cb->p_context);
    }
    
    
/* Rest of function ... */
}

Immediately after startup (when debugging with JLink) an error gets caught in this first if statement and goes on to produce the NO_MEM. SEGGER does not give me a further backtrace and this happens almost immediately. If I do a hard reboot without the JLink Connected it works just fine but attempting to connect the JLink again leads to this error so it is difficult to debug by myself.

[Hung Bui]

Maybe you can trace back to the modification you made to the firmware. 

How do you plan to send data to the bootloader from the application. Please be aware that you still need the mesh bootloader flashed. What the DFU application does is to forward the data packet it receive to the bootloader (by calling nrf_mesh_dfu_cmd_send() ).

You would need to follow what we do in serial_handler_openmesh_rx() and serial_handler_dfu_rx()

[tmwinjy]

I had not made changes to the firmware when I get this error. This appears when I use the base code on my Thingy52. after adding a board_init from the ThingySDK but by this point I had made many changes and still, on occasion get this error.

I just wanted to know what could be wrong with the base code?