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

  • So, I just use bootloader and MBR, the commands is

    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

     I don't know if the commands is correct, so I also try this

    nrfutil settings generate --family NRF52 --application-version 0 --bootloader-version 0 --bl-settings-version 2 settings.hex
    nrfjprog --eraseall -f NRF52
    nrfjprog --program mbr_nrf52_2.4.1_mbr.hex --verify -f NRF52
    nrfjprog --program bootloader.hex --verify -f NRF52
    nrfjprog --program settings.hex --verify -f NRF52
    nrfjprog --reset -f NRF52

    but I can't see any logs. The bootloader is pca10040_uart_debug.

    BR

    Lurn

  • Lurn_Z said:
    If the test passes, how do I update the application.

    you can use nrfutil if you can send UART messages from your computer to your custom board.

    Make sure that in your bootloader project's (pca10040_uart_debug) sdk_config.h file these are set:

    NRF_LOG_ENABLED 1
    NRF_LOG_BACKEND_RTT 1

    They should be set to this by default, but it is worth checking if you can't see any logs.

    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?

    You are able to see the logs from your application, so it should be possible.

    1. What SDK version are you using?

    2. Did you do something particular to make the application run on your custom board in your other application? Did you have to modify/change the board files?

    3. How do you compile your bootloader? (What compiler/IDE do you use?)

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

    5. Does your custom board have an LFXTAL?

  • 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

Reply
  • 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

Children
  • 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? 

  • 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

Related