Unable to understand the steps to perform OTA DFU for ESB application on nRF52840

[Gianlucamilani]

Dear DevZone,

I developed an application based on ESB wireless communication protocol for the nRF52840, and I would like to perform an OTA DFU with it.

I read in this ticket that a possible solution in this case is to leave the softdevice flashed, write your own transport layer for the ESB and use the bootloader provided from Nordic - which is transport agnostic (see also the figure below):

I have two questions about this:

• Do you suggest me to proceed as mentioned there?
• If yes, could you provide me some documentation or give me some hints about the steps to follow to perform this procedure?

Again, concerning the same issue, I have also another doubt:

• Does the above mentioned approach coincide with the one described by Nordic here ('Extending your application to support the BLE DFU Service')? I can't understand if this last one is feasible only for BLE applications or not and, in case not, which approach is better and why.

Thank you very much in advance,

Best regards,

Gianluca

[Gianlucamilani]

Dear Einar,

following your suggestions I started going through the nrf_dfu_serial_uart.c file.

Looking line by line, I firstly tried to understand the main commands to be replicated, then I focused more on the details.

The commands that I would start to bring to the new file for ESB are the following:

• The call to the BALLOC_DEF function, which is present also in the BLE example and which in the UART example is given by the following line:

NRF_BALLOC_DEF(m_payload_pool, (UART_SLIP_MTU + 1), NRF_DFU_SERIAL_UART_RX_BUFFERS);

 

• The call to the initialization functions for the dfu transport, here the lines for uart:

static uint32_t uart_dfu_transport_init(nrf_dfu_observer_t observer);
static uint32_t uart_dfu_transport_close(nrf_dfu_transport_t const * p_exception);

• The call to the REGISTRATION MACRO:

DFU_TRANSPORT_REGISTER(nrf_dfu_transport_t const uart_dfu_transport) =
{
    .init_func  = uart_dfu_transport_init,
    .close_func = uart_dfu_transport_close,
};

• The definition of the transport initialization function in which I would put 
  • the call to the nrf_balloc_init
  • the call to the balloc_alloc
  • the call to the ESB init
• the definition of the transport closing function similar to the uart one

Questions

Now, I still have some very important doubts:

• which are the parameters that I have to choose for the BALLOC_DEF in the ESB case? Are the ones chosen for the UART ok? I saw that for BLE are different and defined through weird functions

NRF_BALLOC_DEF(m_payload_pool, (UART_SLIP_MTU + 1), NRF_DFU_SERIAL_UART_RX_BUFFERS);

• I saw that the nrf_drv_uart_init, which initializes the uart driver:

   err_code =  nrf_drv_uart_init(&m_uart, &uart_config, uart_event_handler);

             has some parameters such as the uart_event_handler and the uart_config which depend from structures that are specifically  designed for DFU, such as the m_serial (which is complex because composed by other functions). The question is: can I initialize the ESB transport without these complex parameters? If not, how is possible to understand how to translate these parameters for the nrf_esb_init?

• Finally, I would like to ask you as expert if you could tell me an estimation on the effort needed to perform this task: initially I thought it could be an easy process having the support of the examples, but now I'm finding them a little bit cryptic.

[Einar Thorsrud]

Hi,

Gianlucamilani said:

which are the parameters that I have to choose for the BALLOC_DEF in the ESB case? Are the ones chosen for the UART ok? I saw that for BLE are different and defined through weird functions

This is to allocate memory buffers for handling the incoming data. You probably need something similar, but it all depends on your implementation. There is nothing in the architecture that dictates that a transport layer must use NRF_BALLOC.

Gianlucamilani said:

The question is: can I initialize the ESB transport without these complex parameters? If not, how is possible to understand how to translate these parameters for the nrf_esb_init?

Yes, you can. This is just a part of the internal transport layer implementation. Specifically, m_serial is nrf_dfu_serial_t, which is there because it is shared between the USB and UART transport. Most of this may not make sense in your ESB transport implementation. Perhaps you should refer to the BLE and ANT transports as well, to see alternative ways of doing it. Essentially the transport itself is all up to you, and the main thing you need to do is to provide the init and close functions to the bootloader, and handle the communication with the DFU master and call nrf_dfu_req_handler_on_req(), where you can use nrf_dfu_serial.c and other transports as reference. It is not straight-forward, but I think it is a good idea to spend some time with the existing transport layers to understand what is generic, and what is just transport-specific (or implementation-specific).

Gianlucamilani said:

if you could tell me an estimation on the effort needed to perform this task: initially I thought it could be an easy process having the support of the examples, but now I'm finding them a little bit cryptic.

It is difficult to estimate. You have other backends to reference, but there is quite a bit you need to understand, and then do the implementation. You also need to implement the DFU master that will do the upgrade over ESB, so you don't have anything known good to start testing with. I cannot say how many days or weeks you need, though.