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

  • Sorry i didn't make it clear.

    The question is I have a program without softdevice, and now I want to update it over UART(I was wrong in the beginning, I said over ESB), so I mast have a bootloader to Implement it, I use the example for test, and all questions are found during testing.

    Now, I use ble_app_uart, bootloader_uart, softdevice_s132 for test, when I don't modify anything, I can find the device like this, and I can see some logs like  connecting... disconnected...

    when I add the code to enter DFU mode (the while loop), I found the device like this,I don't know its current state, because I can't  see any logs.

    Yes, I really mixing up things. So I should use mbr with pca10040_uart_debug and \peripheral\blinky to test ? But in this program I can't enter DFU mode by the while loop, because it can't compile, so if I use blinky to test how should I enter the DFU mode.

    And I will try to program only the mbr and the bootloader.

    BR

    Lurn

  • Ok, let us try to straighten out a few things first, then.

    If you intend to use a UART bootloader, you will not (!) be able to see it from nRF Connect. It is a serial bootloader, so you need to connect to it via UART. 

    If you have a custom board, I am not sure how you intend to connect the UART. I recommend that you get hold of a DK just to test things, to get the understanding of how this works, because on the DK, the default UART pins are routed through the debugger, which translates it to UART over USB, which you can communicate with using a computer. Are you able to see UART data on your custom board?

    If you want to test the UART bootloader, I suggest you only program the bootloader and the MBR. No application. Then the device will enter DFU mode. You will still not see it from the nRF Connect app, because it is only a UART bootloader. No Bluetooth.

    So please clarify this: Since you are referring to the nRF Connect app, does this mean that you want a Bluetooth Low Energy bootloader, or do you actually want a UART bootloader? How do you intend to transfer application updates in the end? Wireless via a phone, or serial via wires?

    BR,

    Edvin

  • yes,I need a UART bootloader to update, so I just need use bootloader and MBR to test?

    If the test passes, how do I update the application.

    BR

    Lurn

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

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

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

Related