Using the DFU SDK 12.1 with a BLE command to jump to 'bootloader' works every other time with nordic connect app

[sananth]

We have been using the DFU that came with the sdk 12.1 with a modification (essentially removing the button from the DFU code). We currently send an application command that will tell the code to 'jump' to the bootloader. This works great. Once the app command is reeived the device begins advertising 'DFUTarg' I use the nrf connect android app to load the .zip file.

It works the first time, and every odd number time after; hence the second time of jumping back to the bootloader it will appear as if the app was loaded properly and nrf conenct will state the app was successfully loaded but when I scan the device still advertises as DFUTarg. If I try to load again, it will say successfully loaded and will advertise with our custom name.

We have the watchdog timer enabled in the application and following some other posts I added NRF_WDT->RR[0] = WDT_RR_RR_Reload; to the wait_for_event loop in the DFU to pet the dog.

Any suggestions?

[sananth]

Hi Bjorn

I added what you recommend to the code, but it still fails sporadically. when the WDT has a timeout of 2000.

Any suggestions?

Thanks again for your help!

[bjorn-spockeli]

I've done some testing with the bootloader where I initialize and start the WDT right after entering main(). I am not seeing any issues with a WDT timeout interval of 2 seconds, so I do not think you should be breaking any timing requirements in the bootloader. When does the failures occur? I would expect that you sometimes could run into some issues as the device is jumping from application mode to bootloader mode, i.e. if you jump at the end of the WDT interval in the application then the WDT might expire before you reach the wait_for_event() loop.

[sananth]

Hi Bjorn,

We start/setup the watchdog right before we enter the

for (;;)
{
    app_sched_execute();
    UTIL_kickWatchdog();
    APP_ERROR_CHECK(sd_app_evt_wait());
}

It is hard to pinpoint when the failure occurs. We currently have an led that is one during the bootloader phase. It most likely is happening at the end of the bootloading (or at least that is my guess). As when it works the led blinks really quickly and shuts off. Versus when it doesn't work the led goes off and within a second is back on. All signs on the nordic phone app make it seem like it correctly boot loaded.

Do you have an suggestions on what to try to debug this better? So I can provide more info

[bjorn-spockeli]

If you debug the bootloader after the DFU, does it reach nrf_bootloader_app_start in nrf_dfu.c (should be at line 143 in nrf_dfu.c)? If so, could you try to debug the application? Lastly, could you read back the flash after a failed DFU to a file and attach it to the question? You can read back the flash and store it to a file using the following command.

nrfjprog -f nrf52 --memrd 0x00000000 --n 524288 >> hex_dump.txt

[sananth]

Hi Bjorn

I ran the above line twice. Once when things load properly (here is the output):

Working Hex file

And when things don't (here is the file):

Not working hex file

I used a hex file comparator and the working one has values in place where the not working one has 0xFF