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

  • 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

  • So, I can use this command to create the .zip ?

    nrfutil pkg generate --hw-version 52 --bootloader-version 2 --bootloader boot.hex --application-version 1 --application application.hex --sd-req 0x00 --key-file private.key update.zip

    BR,

    Lurn

  • Yes. It has been a while since I tested that combination, but give it a go, and let me know if it doesn't work.

    BR,
    Edvin

  • nope, It didn't work

    it not support BL+APP

    But I do not use the softdevice, how can I make this?

    BR,

    Edvin

Reply Children
  • Hello,

    Oh, ok. I see. BL + APP is not supported, but BL + SD + APP is supported. Weird. 

    However, as I mentioned, when you are using the combination BL + SD + APP, then this will be split in two operations. First BL + SD, and then APP. So there is no difference from just doing it in two steps. One image with the BL and one image with the APP, and that should work.

    BR,
    Edvin

  • Ok, I will try it.

    And can I understand in this way? cause I only use BL + APP + MBR, so I can update my device to BL + APP + SD, but can not back?

    Or if I use BL + APP + SD, how to update to my program?

    BR,

    Lurn

  • I believe the limitation comes from the fact that most of our users use the softdevice, and it is a bad idea to update the bootloader and app without updating the softdevice, because updating the bootloader often comes with a version update, so you should update the softdevice so that the BL and SD are not incomatible.

    In your case, if your bootloader doesn't use the softdevice, this requirement doesn't really make sense. But as I mentioned, there is literally no difference between having the BL and APP in the same packet or two. The only difference is that you need to do "nrfutil dfu serial -pkg ..." two times instead of one. It doesn't take longer time, as it is the same amount of data that needs to go through, and the end user will probably not notice a difference, if you are doing this from a custom app or some sort of script either way.

    BR,

    Edvin

  • Yes, I can update it in two steps, but after one step done, I need enter the DFU mode again.

    Whatever, this problem has been solved.

    Thanks a lot.

    BR,

    Lurn

  • I have not tested now, but doesn't it delete the app when you update the bootloader? And doesn't that in turn put it in DFU mode automatically?

    BR,

    Edvin

Related