nrf52832 OTA over ESB based on SDK17.1.0

[Lurn_Z]

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]

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.

[Edvin]

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

[Edvin]

Hello Lurn,

So you are struggling to get the device into DFU mode, is that the case?

If you test the pca10040_uart_debug bootloader project, you can monitor the RTT log. Inside the dfu_enter_check() function in nrf_bootloader.c, you can see the different checks it does to see whether it should enter DFU mode or not. I believe the one you are trying to use now is the GPREGRET method, so make sure that NRF_BL_DFU_ENTER_METHOD_GPREGRET is set to 1 (it is by default).

So if you set the GPREGRET register to 0xB1, then it should enter DFU mode. 

I guess that if you test the pca10040_uart_debug project and check the RTT log, and you do not see DFU mode requested via GPREGRET, then the issue is probably that the gpregret was not written before you reset. 

You can read out the gpregret manually by using the nrfjprog command:

nrfjprog --memrd 0x4000051c

To see whether it is written.

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

#define BOOTLOADER_DFU_GPREGRET_MASK            (0xB0)         
#define BOOTLOADER_DFU_START_BIT_MASK           (0x01)     
#define BOOTLOADER_DFU_START        (BOOTLOADER_DFU_GPREGRET_MASK | BOOTLOADER_DFU_START_BIT_MASK)



...
{
    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();
}

Best regards,

Edvin

[Lurn_Z]

Hello Edvin:

I used the command to read out the gpregret, but the value is 00000000.

Best regrads,

Lurn

[Edvin]

So did you use the while loop to wait for it to be set correctly?

BR,
Edvin

[Lurn_Z]

yes, I used it, but my rtt does not display logs. so I don't know what's wrong.

ps: I used the pca10040_uart_debug, so It should display logs

[Lurn_Z]

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

[Edvin]

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

[Lurn_Z]

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.

[Lurn_Z]

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

[Edvin]

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

[Lurn_Z]

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