Android app "nRF Device Firmware Update" and "Android-DFU-library" fail at DFU

[afarre]

Hello,

I have a firmware working properly at bluetooth DFU when using apps "My-nRF52 Toolbox" or "nRF Connect for Mobile".

But if I use app "nRF DFU" I get "error: the device does not support nrf52 dfu".

I get similar error with my own app buid with "Android-DFU-library".

I am using nRF52840, with nRF SDK 17.1.0 through Segger, and DFU zip file is built with latest nrfutil version.

Please find attached the verbose log I get at "nRF DFU".

Thank you.

[Hung Bui]

Hi Alberto, 

Could you let me know what you flashed on your application ? Did you flash the bootloader ? 
If you only flash the bootloader + softdevice did you manage to do a DFU update with the app "nRF Device Firmware Update" ? 
From what I can see in the log, the app managed to connect to your application but when switching to bootloader it doesn't see the bootloader advertising, instead it's the application was running. 
Do you use WDT in your app ? 
Have you tried to test with our ble_app_buttonless_dfu example ?

[afarre]

Hello Hung,

First of all, I have to apologize because I haven’t tried first an easier setup as you suggest but, because it does work with "My-nRF52 Toolbox" or "nRF Connect for Mobile” I was in the hope it would be something ease.

Once trying with nRF52840-DK (PCA10056), "nRF DFU" does work not only with ble_app_buttonless_dfu example but also with my own application (a limited version to run at PCA10056 without hardware peripherals).

"nRF DFU" still fails when using my whole application which can only be applied to my custom hardware based on nRF52840. But starting from this point I believe I can manage to find out what is happening. Once sorted the problem out I will report here what is happening.

Regard your questions:

No, my application does not use WDT.

At wired flashing, I play following command lines:
nrfjprog -f nrf52 --eraseall
nrfjprog -f nrf52 --program bootloader.hex
nrfjprog -f nrf52 --program s140_nrf52_7.2.0_softdevice.hex
nrfjprog -f nrf52 --program firmware.hex
nrfjprog -f nrf52 --program settings.hex
nrfjprog -f nrf52 --reset

I generate the zip file for wireless DFU with following command line:
nrfutil pkg generate --application firmware.hex --application-version 1 --hw-version 52 --sd-req 0x0100 --key-file private.pem dfu-app-release.zip

Obviously, the private.pem key file matches the key inserted a bootloader generation.
Bootloader generation is closely the same that comes with SDK at examples\dfu\secure_bootloader\pca10056_s140_ble

I hope this answer your questions.

[Hung Bui]

Hi Alberto, 

From the log in the screenshot what I can see is that after the app switch the application to DFU mode the app couldn't find the bootloader (usually at original address +1  ) when it couldn't find the bootloader, it try to connect to the original address and then it couldn't find the DFU service, most likely the normal application was running, not the bootloader. 

I would suggest to try:

1 - Only use bootloader + softdevice, then try to use the nRF Device Firmware Update to do DFU. 

2 - Test with your application, but this time switch to bootloader manually, by enable indication then write 0x01 to the buttonless characteristic. Then do DFU from there (connect to bootloader manually like in step 1)

If both of the above work, then we need to look into why it couldn't do those steps automatically. 

I would suggest to use the sniffer to track what's going on over the air and you can compare the process between different apps. 

[afarre]

SOLVED

Some developer forgot time ago following commented out code at main.c of bootloader (green color).

I do not know why it is harmful for "nRF DFU" and why it is safe for "My-NRF52 Toolbox" and "nRF Connect for Mobile, but once commented out this code everything works fine.

Thnaks to your directions I could find this prob by comparing with original main.c at secure bootloader example.

Thank you very much for your support.

[Hung Bui]

Hi Alberto , 
I'm glad that you figured it out. 
If I understand the extra code correctly, when the bootloader starts it will blink some LEDs and this can take about 1.6 seconds. 

And if you notice in the screenshot, the timeout for the DFU library is only 2 seconds    So what happened was that when scanning for the bootloader (address +1), the DFU library couldn't find it and then it gave up and looked for the original address. When connected to the original address (most likely the application) it couldn't find the DFU service.