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

[Einar Thorsrud]

Hi,

Do you suggest me to proceed as mentioned there?

No. This post is quite old, and since then the bootloader has been updated to not rely on the SoftDevic (unless you need a BLE transport). You can refer to the serial bootloader examples to see to use the bootloader without a SoftDevice. Essentially there is no difference other than the transport since there are libraries that abstract away the difference with and without SoftDevice (most importantly fstorage). The MBR is needed, but that is available separately, and not just as part of a SoftDevice.

If yes, could you provide me some documentation or give me some hints about the steps to follow to perform this procedure?

There is no explicit guide for making a new transport, but you can refer to the existing implementations and the documentation for the DFU protocol.

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.

This section described how to add support for buttonless DFU. Essentially a way to trigger DFU from the application instead of signaling it by for instance holding a button while resetting. In the BLE context, we provide an example using a BLE service, and the possibility to share BLE bonding information between the application and bootloader. For ESB this would probably be as simple as just writing to GPREGRET and performing a soft reset.

[Gianlucamilani]

Ok thank you very much Einar, I will start following your suggestions.

So, do you think I could start from the serial bootloader example as base for my bootloader, or is it the same also if I use the BLE one and then I proceed registering the ESB transport layer ?

[Einar Thorsrud]

Hi,

It does not matter where you start really, as in the bootloader the only difference is the transport. The only difference is that the example with the BLE transport includes the SoftDevice and the serial bootloader examples only include the MBR. But that is just a matter of a few preprocessors defines, includes, flash layout, etc, but the code would be the same (and you can easily change later).

[Gianlucamilani]

Dear Einar, 

thank you very much for your answer, I am studying the material available in the InfoCenter.

I also found this post in which a UART transport layer is added starting from the BLE bootloader example. 

I saw that the tranport layer is registered through DFU_TRANSPORT_REGISTER within some specific files (nrf_dfu_ble.c for BLE and nrf_dfu_serial_uart for UART). Here, the uart and ble DFU transport initialization functions are defined (uart_dfu_transport_init for instance), see the figure below:

I have a question:

• could you help me in understanding which is the approach I have to follow to build the same function for ESB?
• Is this needed for achieving my goal? Or is there a simpler way?

Thank you very much in advance, 

best regards,

Gianluca

[Einar Thorsrud]

Gianluca,

This is the correct approach, yes. I suggest you just refer to existing implementation (perhaps serial UART as that is simplest), and implement corresponding functionality for ESB. That men's that the following files are most relevant:

• components/libraries/bootloader/serial_dfu/nrf_dfu_serial.c
• components/libraries/bootloader/serial_dfu/nrf_dfu_serial_uart.c

You will have to implement the same as these files, but using ESB instead of UART.

Einar