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.

[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?

[Hung Bui]

Hi, 

I think we need to have some clarification here.

Please let us know what exact firmware you are using, on which hardware board.

Is the "base code" you mentioned the default Thingy code  ? We don't have mesh supported in that code. Please give us the exact link to the code you use. 

What are you planning to create in your application ? 

[tmwinjy]

CONTEXT:

Mesh SDK v2.2.0

SDK15.0.0

NordicThingy52 DK.

PROCESS:

I follow the steps for making the ble_uart_coexist project. No modification to code is done. I simply move the files to their required locations.

RESULT:

Upon runtime, I immediately get a NO_MEM error in the places previously stated.

QUESTION:

I am wondering why I receive this error if I simply run the program without any modifications.

AFTERWORD:

As for what I am trying to do, I am attempting to go through the steps you laid out for me upon suggesting I use this example as the base code for the DFU module I am trying to make. This is my final goal.

[Hung Bui]

First please make sure the ble_uart_coexist works fine on your thingy, meaning you can receive UART and send it to a phone, at the same time can do mesh light switch activity. 

Do you know how exactly the mesh bootloader works ? How you plan to integrate DFU support in your application ? 

There are 2 big steps needed: 

1. Integrate DFU feature and bootloader in to your application (so that it can accept DFU update) and execute it. This is normal bootloader that you can receive image via UART, not BLE.

2. Change what in 1 so that the image can be received in BLE instead of UART. 

Both steps requires you to have deep understanding on how the Mesh bootloader works. 

I strongly suggest to start your development on a NRF52 DK, not the Thingy. The Thingy is not made to be a development board, it's a prototyping platform. 

[tmwinjy]

I can carry out the light switch activity just fine. I am honestly not 100% sure on how the mesh bootloader works.

I have read the documentation and I think I have a general idea but the specifics of DFU in bootloader mode escape me. The side by side DFU makes sense but is hard to modify to BLE as I do not know how the UART works.

Currently, I have removed the UART parts of the ble_uart_coexist. I plan on keeping the mesh framework but adding the BLE_DFU functions around it and morphing the program into a bootloader of sorts. I have already stripped the UART code and my mesh is still initializing and provisioning. Now I am in the process of adding the BLE to receive the image. then I will send those packets over the mesh to be received by the other boards using the existing mesh_dfu code.

I agree that an NRF52 DK would be ideal but am restricted to the Thingies for the time being.

Thank you for the responses. I will let you know how this works out.

[Hung Bui]

Hi , 

I need to correct myself, you don't need to integrate the bootloader into your application. You can just use the bootloader as is. Just modify the application to forward the BLE message to the bootloader the same way as we do in serial_handler_openmesh_rx() and serial_handler_dfu_rx() in the DFU example (the DFU application, not the bootloader). 

So your first step is to integrate the serial DFU feature into  your application. You still flash the original bootloader + your dfu app. 

I would suggest to get familiar with the DFU application.

I don't think it's a good idea to continue with the Thingy as it doesn't have serial interface , strongly suggest you to get hold of a nRF52 DK. Cost only $39 and will save you lots of time.