After performing a DFU, my device is stuck in DfuTarg Automatised DFU with Android

[BasileC]

Hello everyone,

I'm currently facing two problems :

1- I'm using nrf Toolbox with the last version and perform a DFU on a low_energy_ble device. I'm using a .zip and got no trouble while doing it. But after this my device is stuck in DfuTarg (MAC_ADDRESS+1). I tried the setting External MCU DFU without succes and its seems my device is stuck in the bootloader and cant jump to the app. I can do the same procedure with another device who then got the right app/boot version and is ready to use without any problem. Have you ever got this case and how to force the jump in the application ?

2 - I want to automatised this process with a script so i work with the Nordic script :dfu_win_3_1.bat 
All the requirements are fine and im almost fine but i got an error : Upload failed : INSUFICIENCE RESSOURCES

Here is the command line which put m in trouble :

adb shell am startservice -n no.nordicsemi.android.nrftoolbox/.dfu.DfuService

-a no.nordicsemi.android.action.DFU_UPLOAD

-e no.nordicsemi.android.dfu.extra.EXTRA_DEVICE_ADDRESS XX:XX:XX:XX:XX:XX

-e no.nordicsemi.android.dfu.extra.EXTRA_DEVICE_NAME DfuTarg

--ei no.nordicsemi.android.dfu.extra.EXTRA_FILE_TYPE 0

--ez no.nordicsemi.android.dfu.extra.EXTRA_KEEP_BOND false

-e no.nordicsemi.android.dfu.extra.EXTRA_FILE_PATH "/sdcard/Nordic\ Semiconductor/Upload/connectivity_1.1.0_115k2_with_s130_2.0.1.hex"

-e no.nordicsemi.android.dfu.extra.EXTRA_INIT_FILE_PATH "/sdcard/Nordic\ Semiconductor/Upload/app_dfu.zip"

I tried with different nrf toolbox version and each one got a different output...
Have anyone run this Nordic script successfully ? Where is my error ?

Thanks and forgive my poor english

[BasileC]

EDIT--

For the device stuck in DFU, when i flash an old version, the device operate good.

So it seems some diff with the 12 last commits can solve the problem

[Vidar Berg]

Hello,

1. Does app boot if you repeat the DFU process, or does it remain in DFU mode? Reason I ask is that a WD timer running from the App may cause the the initial upload to fail (bootloader must reload WD during upload and activation to avoid WD reset). 

The debug version of the bootloader (_debug postfix in project name) has logging over RTT enabled, which will report any errors in the process( e.g., if post validation step fails). I would recommend to capture the log to get more information.  

2.  I've not used the library myself, but I belive EXTRA_FILE_PATH  should point to your DFU .zip package. From the API doc: 

/**
	 * A path to the file with the new firmware. It may point to a HEX, BIN or a ZIP file.
	 * Some file manager applications return the path as a String while other return a Uri. Use the {@link #EXTRA_FILE_URI} in the later case.
	 * For files included in /res/raw resource directory please use {@link #EXTRA_FILE_RES_ID} instead.
	 */

The connectivity_1.1.0_115k2_with_s130_2.0.1.hex contains connectivity FW merged with the s130 softdevice, and therefore too big to fit in the app region. 

[BasileC]

1.I will look for this WD, it can be the cause.

2. Look like i just reverse EXTRA_FILE_PATH and EXTRA_INIT_FILE_PATH
It works now thanks !