If first DFU fails, the app is broken

[Julien]

Hi,

I have a problem when i try a dfu on my device for the first time.

To explain, my device is flashed the first time with NRFJPROG, and i flash the SD+BOOT+APP.

So my device is working well.

Then i when to upload the firmware, so i realize a dfu.

It's a dual bank bootloader.

If the dfu fails for somehow reason, my device is broken, the app does not started, and the device is not advertising.

But only if it's the first time we try. If the first try succeed, the app start like expected.

Then if we try a 2nd DFU and that fail, the device start the previous application stored.

I think my application is still present, because i saw it with nrf connect once the device is broken.

It seems the bootloader does not have the start address of the application.

For the moment i'm blocked here, and I hope you could help me.

My device is a NRF52832, and i work withe SD 132_6.1.0

Thanks,

[Julien]

He seems to me that we we don't understand each other.

So my problem is not the dfu fails, is why when the dfu fail my device doesn't restart the application.

For me it's important because my two device could be moving during the process and i need to be sure if a loss connection occurs my peripheral is not broken.

For the test, i simply switched off my central to fails the dfu, but it's just for the example.

If my peripheral is only programming by nrfjprog and none dfu has occur on him before, my peripheral doesn't start again, and after readed the register i look the "PC" register i saw the device is blocked at the address 0x00024D36, an address of the softdevice.

But i simply switched off my central during a dfu of a peripheral who a dfu has already occur before. The application start after the fail.

So my question is why we have two behaviour.

It seems like something is not set on the first time. In debugging, i see after an error of dfu, the dfu settings changed. The bank current change but for the first behaviour nothing is set.

I show you the different state of the dfu settings struct

Init state, the device is only flash by nrfjprog, we haven't try to make a dfu :  

First try of dfu, dfu fails, the app never start after the fail : 

And a dfu has already success on the peripheral, but a 2nd dfu fail, the app restart after the fail : 

Do you think my problem come from here?

Thanks

[Amanda Hsieh]

Hi Julien, 

Could you use nRF Connect- Programmer to connect the device to display the memory contents and provide the figure after causing the error?

-Amanda H.

[Julien]

We have that, looks like normal to me

[Amanda Hsieh]

Hi,

You state that you have flashed the SD+APP+BL, so it could be that you do not flash the bootloader settings hex. In that case, the nRF52832 will start in the bootloader and the bootloader settings might look like his first screenshot, where the bank_0.bank_code is 0x00( NRF_DFU_BANK_INVALID) even though there is an application flashed to the nRF52832.

In this case, the bootloader will advertise as DfuTarg and the customer can connect to the nRF52832 and perform a DFU. You say that the DFU fails the first time. Could you provide the nRF Connect log from this failure and possibly the bootloader log (if you are using the debug version of the bootloader)?

The old application will not be invalidated until the new application image has been received in full and postvalidated. During this postvalidation step, the bank_1.bank_code will also be set to NRF_DFU_BANK_VALID_APP, see postvalidate_app() in nrf_dfu_validation(). After the postvalidation step, the bootloader will then reset and enter nrf_bootloader_fw_activate() from nrf_bootloader_init() and will then call app_activate() if bank_1.bank_code == NRF_DFU_BANK_VALID_APP.

Hence, I would ask you to set breakpoints in postvalidate_app() as well as nrf_bootloader_fw_activate and app_activate() to check if there is something that goes wrong here.

-Amanda H.

[Julien]

Ok thank you for the answer.

How Ican flash the bootloader settings hex? And the application start after flashing the SD+APP+BL, we are not advertising as DFUTarg, although I have No firmware to activate in function "nrf_bootloader_fw_activate()".

The DFU fails is caused by me just for a failure test. So i don't think the log would be useful, and the DFU is not realize by the nrf connect app, but by a ble central device.