DFU bootloader cannot automatically start a valid application after timeout

[PeteKcSum]

Hi Nordics,

we would like our central nRF52840 to have DFU timeout in 20 seconds , if no connection received via nRFconnect phoneAPP to perform the firmware udpate, then go to application, just as in this case

https://devzone.nordicsemi.com/f/nordic-q-a/44641/ota-dfu-with-a-timer-and-no-button .

However , the DFU is not able to timeout and only keeps waiting forever for the phone APP to link and perform a zip write to it.

we have merged the secure DFU bootloader with the settings based on the following posts

https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/getting-started-with-nordics-secure-dfu-bootloader

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fug_nrfutil%2FUG%2Fnrfutil%2Fnrfutil_settings_generate_display.html

and also set the sdk_config so that the DFU timesout in 20000ms

which have not solved the problem. Any clues will be appreciated to help solve the issue , thx.

BTW, as shown below, our application size is 93831 bytes, while the bootloader settings.hex indicates that the application size is only 33344 bytes, is there something wrong with that, which could be causing the issue ?

[Einar Thorsrud]

Hi,

I tested with an SDK 16 secure bootloader example, where the only modification from was to reduce the timeout to 20 seconds. In this case, the device was reset after 20 seconds without any connection. Which SDK version do you use? And how do you trigger DFU mode?

Regarding the application sizes that is not a correct comparison, since the bootloader settings give you the size of the binary, whereas the .hex file is the binary in intel hex format, which as a lot of overhead. I would be surprised if this is a problem, but you can always check the size of the binary in nRF Connect Programmer, which gives you a graphical representation of the image with start and stop addresses.

[PeteKcSum]

Hi Einar ,

the SDK used is 15.2. The DFU is triggered using the following code

void EnterDFU(void)
{
    #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)      
    sd_power_gpregret_clr(0,0xffffffff);
    sd_power_gpregret_set(0, BOOTLOADER_DFU_START);
    nrf_pwr_mgmt_shutdown(NRF_PWR_MGMT_SHUTDOWN_GOTO_DFU);
}

which is setting the GPREGRET and then reset to enter DFU, thx.

[Einar Thorsrud]

I see. I asked was that since I am unable to reproduce the behavior where the bootloader does not reset, I am wondering if it does reset, but it just does not start the application? Can you test the debug bootloader with RTT logging to see if it does reset after every 20 seconds (as is the case on my side), or if it does indeed stay in the bootloader more than it should even when no phone connects to it?

It could be that after every timeout the bootloader would still think it should enter DFU mode. But that would only be the case if you modified dfu_enter_flags_clear(), wince that will clear the BOOTLOADER_DFU_START in GPREGRET. 

Another explanation for the bootloader to always enter DFU mode after every reset (every 20 seconds) is if there is no valid application. Have you made sure that the application is valid and can be started by the bootloader? The RTT log will clearly show if the problem is an invalid application (either valid flag not set or CRC mismatch compared to the bootloader settings).