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 can't find my device by nrf connect, I suspect the device is not started。

  • Lurn_Z said:
    I used the pca10040_uart_debug, so It should display logs

    What are you using to monitor the logs? Segger RTT Viewer? Do you see logs from other examples that use RTT logging, such as the ble_app_uart (when you do not use a bootloader)?

    Are you running this on a DK or on a custom board? If it is a custom board, can you please try on a DK first?

    Lurn_Z said:
    I can't find my device by nrf connect, I suspect the device is not started。

    What do you expect to find? The device advertising as ble_app_uart? Or the bootloader? Perhaps you can share some screenshots so that I can understand a bit better what exactly you are trying and seeing right now.

    BR,

    Edvin

  • I used RTT Viewer to monitor the logs, and I don't have DK board.

    Neither all terminals nor terminal 0 displays any logs.

    In this link when ues nrfjprog to flash the hex file, you can find advertising as "DFUTarg" or something, but I can't find the advertising about Nordic.

  • Do you see logs from other examples that use RTT logging, such as the ble_app_uart (when you do not use a bootloader)?

     yes, when I use my progrem, I can see the logs

  • Hmm. Ok. Are you sure you programmed the MBR when you program the pca10040_uart_debug bootloader? (The mbr is found in sdk\components\softdevice\mbr\hex\mbr_nrf52_2.4.1_mbr.hex)

    Can you try setting a breakpoint at the start of the bootloader's main() function? Is it triggering?

    Lurn_Z said:
    In this link when ues nrfjprog to flash the hex file, you can find advertising as "DFUTarg" or something, but I can't find the advertising about Nordic

    That is only if you use the BLE bootloader (pca10040_s132_ble). This also requires that you flash the softdevice.

    I think we are mixing up a few things here. You started by saying that you wanted a bootloader with transport over ESB. Is that really the case? Or do you want a BLE bootloader, that you can update through your phone? 

    From your last log, I can see that you are using an application. Did you program this together with your bootloader (pca10040_uart_debug)? Try to only program the uart debug bootloader and the mbr, and then see if you can see any logs. If you want to program your application as well, you need to change it's start address. If you intend to use the softdevice (Bluetooth stack), you need to set the application's start address to after the softdevice (address depends on your SDK and softdevice version), while if you intend to use ESB only, and not BLE, then you need to adjust your application to start after the mbr (addr. 0x1000).

    So... Try to program only the mbr and the bootloader. Do you see any logs?

    BR,

    Edvin

Reply
  • Hmm. Ok. Are you sure you programmed the MBR when you program the pca10040_uart_debug bootloader? (The mbr is found in sdk\components\softdevice\mbr\hex\mbr_nrf52_2.4.1_mbr.hex)

    Can you try setting a breakpoint at the start of the bootloader's main() function? Is it triggering?

    Lurn_Z said:
    In this link when ues nrfjprog to flash the hex file, you can find advertising as "DFUTarg" or something, but I can't find the advertising about Nordic

    That is only if you use the BLE bootloader (pca10040_s132_ble). This also requires that you flash the softdevice.

    I think we are mixing up a few things here. You started by saying that you wanted a bootloader with transport over ESB. Is that really the case? Or do you want a BLE bootloader, that you can update through your phone? 

    From your last log, I can see that you are using an application. Did you program this together with your bootloader (pca10040_uart_debug)? Try to only program the uart debug bootloader and the mbr, and then see if you can see any logs. If you want to program your application as well, you need to change it's start address. If you intend to use the softdevice (Bluetooth stack), you need to set the application's start address to after the softdevice (address depends on your SDK and softdevice version), while if you intend to use ESB only, and not BLE, then you need to adjust your application to start after the mbr (addr. 0x1000).

    So... Try to program only the mbr and the bootloader. Do you see any logs?

    BR,

    Edvin

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

Related