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.

  • 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

  • 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

Related