nrf52832 OTA over ESB based on SDK17.1.0

Hi everyone:    I developed an application based on ESB wireless communication protocol ofr the nRF52832, and I would like to perform an OTA DFU with it.    Do you know any example of some over the air FW upgrade of nRF52832 chip via ESB protocol.

    SDK is 17.1.0.

Best regards,

Lurn.

Parents
  • I only found examples of ble and uart in the dfu/secure_bootloader folder, Which one should I use or how should I modify it to adapt my program.

  • Hello,

    It is correct that you will only find BLE and UART in our samples, but I know that several customers have ported this to SPI, so if you need it over ESB, then that should also be possible. The transport layers in the bootloader for the nRF5 SDK are on purpose quite separated from the rest of the libraries, to make it easier to change the transport layer, or to add your own transport layer.

    But you do need to implement it yourself. Also note that we do not have the "DFU Master" as an official part of our SDK. We have tools like nrfutil (open source) or nRF Connect for Desktop (not open source), and applications for mobile phones that are open source (but mobile phones doesn't have ESB). However, there is an unofficial implementation (not properly tested. You can use it, but on your own "risk"), which you can find here. I have not tested these myself, but you can give it a go. I suggest you test out the UART master, in combination with the uart bootloader, and then you can port both to ESB once you are up and running.

    Best regards,

    Edvin

  • I guess that the application is using parts of the RAM that the bootloader used for RTT logging. Try to open two different logs, one on address 0x0x2000278C and one on address 0x20006124, and see if you can get both logs.

    They are not running at the same time, so it should not be a problem that the Ram is re-used by the application after the softdevice is done.

  • Hi Edvin,

    Maybe I can't start two rtt viewer cause when I connect the second, the first rtt connection will be lost.

    But, I think the DFU function is ok, and it can enter application just without logs. I can see the logs through debug.

    Maybe we can put this question aside for now.

    I said before that I need to use another device to update the nrf device.

    The device is Android(not phone) and connected to nrf device through uart, so should I still use this command to update?

    nrfutil dfu serial -pkg dfu_image.zip -p COM3 -fc 0 -b 115200

    BR,

    Lurn

  • If you are able to run nrfutil on the Android device, then yes. (You may need to correct the COM port). If not, then you need to look at the implementation of nrfutil, and port it to your Android device.

    Alternatively, you can look at the DFU master implementation from the DFU getting started guide.

    BR,

    Edvin

  • Hi Edvin,

    If I need to update all hex (bootloader, application and mbr/softdevice), which command should I use?

    I only find the command to update application or bootloader alone in this link

     BR,

    Lurn

  • Hello Lurn,

    You can generate a packet using nrfutil containing all 3 (BL + SD + APP). If you do not use the softdevice, then you don't need to update the MBR. It is always the same in all SoftDevice versions.

    If you update the SD you should always update the BL in the same packet (if you use SD), if the softdevice update is a major version update. This is to ensure that the softdevice used by the bootloader and the bootloader itself is matching. 

    When you create a BL (+SD) + APP update image using nrfutil, and perform the DFU, it will be split into 2. BL (+SD) first, and then application when that is done. So whether you generate one image containing BL and APP, or one image for each doesn't really matter. When the BL is updated the app is deleted, and it will enter DFU mode either way.

    BR,

    Edvin

Reply
  • Hello Lurn,

    You can generate a packet using nrfutil containing all 3 (BL + SD + APP). If you do not use the softdevice, then you don't need to update the MBR. It is always the same in all SoftDevice versions.

    If you update the SD you should always update the BL in the same packet (if you use SD), if the softdevice update is a major version update. This is to ensure that the softdevice used by the bootloader and the bootloader itself is matching. 

    When you create a BL (+SD) + APP update image using nrfutil, and perform the DFU, it will be split into 2. BL (+SD) first, and then application when that is done. So whether you generate one image containing BL and APP, or one image for each doesn't really matter. When the BL is updated the app is deleted, and it will enter DFU mode either way.

    BR,

    Edvin

Children
Related