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‘m sure sdk_config.h file are set like you said.

    Make sure that you program the mbr and the bootloader, reset the device (nrfjprog --reset), and then open Segger RTT Viewer (in that order). Still no logs?

    so I just program the mbr and bootloader without settings.hex?

    For your question.

    1. SDK is 17.1.0

    2. I just modify the uart TX/RX pin.

    3.The IDE is Keil5.

    4.I will try this.

    5.I only have a 32MHz Crystal

    BR

    Lurn

  • 4. Did you try debugging the bootloader? Set a breakpoint inside main(). Is it reached?

    The debugging process is OK, I will retry to program bootloader and mbr, maybe something wrong when I programing.

    5.I only have a 32MHz Crystal

    Sorry, I also have a 32.768khz clk.

    BR

    Lurn

  • Lurn_Z said:
    so I just program the mbr and bootloader without settings.hex?

    Yes. The settings are not needed to test the bootloader. The purpose of the settings is that the bootloader will accept the already programmed application, but since you do not program any application, for the purpose of making the bootloader enter DFU mode, you don't need settings.hex. And to clarify, if the bootloader doesn't find an application programmed, it will enter DFU mode.

    Lurn_Z said:
    2. I just modify the uart TX/RX pin.

    So are these actually connected to anything, or are they floating?

    Lurn_Z said:
    4.I will try this.

    Do that, and let me know what you see.

    BR,

    Edvin

  • Lurn_Z said:
    2. I just modify the uart TX/RX pin.

    So are these actually connected to anything, or are they floating?

    I just modify the UART TX/RX pin number, the rx default config is nrf_gpio_cfg_input(p_config->pselrxd, NRF_GPIO_PIN_NOPULL).

    Do that, and let me know what you see.

    The debugging process is OK, I will retry to program bootloader and mbr, maybe something wrong when I programing.

    00> <info> app: Inside main
    00> 
    00> <debug> app: In nrf_bootloader_init
    00> 
    00> <debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
    00> 
    00> <debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
    00> 
    00> <debug> nrf_dfu_settings: Using settings page.
    00> 
    00> <debug> nrf_dfu_settings: Copying forbidden parts from backup page.
    00> 
    00> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
    00> 
    00> <info> nrf_dfu_settings: Backing up settings page to address 0x7E000.
    00> 
    00> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
    00> 
    00> <debug> app: Enter nrf_bootloader_fw_activate
    00> 
    00> <info> app: No firmware to activate.
    00> 
    00> <info> app: Boot validation failed. No valid app to boot.
    00> 
    00> <debug> app: DFU mode because app is not valid.
    00> 
    00> <info> nrf_bootloader_wdt: WDT is not enabled
    00> 
    00> <debug> app: in weak nrf_dfu_init_user
    00> 
    00> <debug> app: timer_stop (0x20000020)
    00> 
    00> <debug> app: timer_activate (0x20000020)
    00> 
    00> <info> app: Entering DFU mode.
    00> 
    00> <debug> app: Initializing transports (found: 1)
    00> 
    00> <debug> nrf_dfu_serial_uart: serial_dfu_transport_init()
    00> 
    00> <debug> nrf_dfu_serial_uart: serial_dfu_transport_init() completed
    00> 
    00> <debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
    00> 
    00> <debug> app: Enter main loop
    00> 

    Is our DFU mode standard DFU? I mean I can see its name like ...DFU... on any device?

    BR,

    Lurn

  • Lurn_Z said:
    I just modify the UART TX/RX pin number, the rx default config is nrf_gpio_cfg_input(p_config->pselrxd, NRF_GPIO_PIN_NOPULL).

    What did you change them to, and what are they connected to?

    Lurn_Z said:
    Is our DFU mode standard DFU? I mean I can see its name like ...DFU... on any device?

    The log that you posted now indicates that your bootloader is running, and that you are in DFU mode! 

    No, you will not. This is a UART bootloader. Where exactly did you want to see it? 

Reply
  • Lurn_Z said:
    I just modify the UART TX/RX pin number, the rx default config is nrf_gpio_cfg_input(p_config->pselrxd, NRF_GPIO_PIN_NOPULL).

    What did you change them to, and what are they connected to?

    Lurn_Z said:
    Is our DFU mode standard DFU? I mean I can see its name like ...DFU... on any device?

    The log that you posted now indicates that your bootloader is running, and that you are in DFU mode! 

    No, you will not. This is a UART bootloader. Where exactly did you want to see it? 

Children
  • Or, let me rephrase the last question:

    How do you want to update the device? From where do you want to send your new application to the nRF?

  • What did you change them to, and what are they connected to?

    No, I didn't change it, I mixed the other ticket answer.

    How do you want to update the device? From where do you want to send your new application to the nRF?

    I want to update the device by UART, and I will send it to nrf through the UART of other board.

    Do I need to do anything on other boards? For example on PC I need to use nrfjprog to update.

  • I program the mbr and bootloader, after enter dfu I use this command to update

    nrfutil sfu serial -pkg dfu_img.zip -p COM3 -fc 0 -b 115200

    It don't work, logs are here.

    when change 115200 to 9600, I only get one line  >>  app:Received an error: 0x0000004!

    So, did I forget something? All command is here.

    nrfutil settings generate --family NRF52 --application app.hex --application-version 0 --bootloader-version 0 --bl-settings-version 2 settings.hex
    nrfutil pkg generate --application app.hex --application-version 2 --sd-req 0x00 --hw-version 52 --key-file private.key dfu_image.zip
    
    nrfjprog --eraseall -f NRF52
    nrfjprog --program mbr_nrf52_2.4.1_mbr.hex --verify -f NRF52
    nrfjprog --program bootloader.hex --verify -f NRF52
    nrfjprog --reset -f NRF52
    
    
    nrfutil dfu serial -pkg dfu_image.zip -p COM3 -fc 0 -b 115200

    Another questions:

    1.Now I can enter DFU because I didn't program my application, so when I also program application.hex and settings.hex, how should I enter the DFU mode?

    2.My application used UARTE, will it affect my use of uart in bootloader?

    BR,

    Lurn

  • Lurn_Z said:
    No, I didn't change it, I mixed the other ticket answer.

    In that case, I suggest we only focus on one ticket at the time. I suggest this one, and we can continue with the other when this one is solved.

    Lurn_Z said:
    when change 115200 to 9600, I only get one line  >>  app:Received an error: 0x0000004!

    That is because you are using the wrong baud rate. Change it back to 115200.

    I still think you would have saved yourself a lot of trouble by getting up and running on a DK before attempting to do this on a custom board, and you may still save time by doing so.

    So it fails to send the serial response. The only possible reason I can think of is that you have enabled hardware flow control (HWFC) in your bootloader project. Try to disable it by setting:

    #define NRF_DFU_SERIAL_UART_USES_HWFC 0

    in your sdk_config.h (It is set to 1 by default. Search for this define in your bootloader's sdk_config.h).

    Lurn_Z said:
    I want to update the device by UART, and I will send it to nrf through the UART of other board.

    In that case, you will not see it in your nRF Connect for Android/iOS, as you would if you were using the BLE bootloader, for obvious reasons.

    Lurn_Z said:
    Do I need to do anything on other boards? For example on PC I need to use nrfjprog to update.

    From the other board, you need to transfer the image. For how to do this, I am afraid we don't have a very good documentation. You can look into the DFU library. There are some useful links from here. Alternatively, you need to look at the implementation of nrfutil (on github)

    Lastly, we have an unofficial implementation of the DFU master, which you can find in this tutorial:

     Getting started with Nordic's Secure DFU bootloader, a step by step guide 

    (Search for DFU master code).

    Best regards,

    Edvin

  • So it fails to send the serial response. The only possible reason I can think of is that you have enabled hardware flow control (HWFC) in your bootloader project. Try to disable it by setting:

    #define NRF_DFU_SERIAL_UART_USES_HWFC 0

    Yes, this is the wrong reason. Now I can update my device successfully.

    I have a question now.

    How should I enter the DFU mode when my device in application?

    I don't think I can use the while loop that you suggest before, because I didn't use softdevice now(I used the wrong example to test before).

    To see whether it is written.

    So to fix this, you can use something like this:

    {
        uint32_t old_gpregret = sd_power_gpregret_get();
        uint32_t new_gpregret = old_gpregret & BOOTLOADER_DFU_START; //Just to retain other things written to gpregret. Not necessarily needed.
        uint32_t temp = 0;
        
        sd_power_gpregret_set(new_gpregret);
        while ((temp & BOOTLOADER_DFU_START) != BOOTLOADER_DFU_START)
        {
            // Wait until the gpregret is written, and refresh the value of temp.
            sd_power_gpregret_get(0, &temp);
        }
        // When this is reached, the gpregret is successfully written.
        nrf_pwr_mgmt_shutdown(NRF_PWR_MGMT_SHUTDOWN_GOTO_DFU);
        NVIC_SystemReset();
    }

    maybe I still need to modify gpregret, but can not use the function sd_power_gpregret_set() ?

    From the other board, you need to transfer the image. For how to do this, I am afraid we don't have a very good documentation. You can look into the DFU library. There are some useful links from here. Alternatively, you need to look at the implementation of nrfutil (on github)

    I will view and study these materials

    BR,

    Lurn

Related