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,

[Amanda Hsieh]

Hi, 

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

That is expected. 

During a Single-bank update, the existing application is preserved until the new firmware image is activated. If the firmware update process fails, you can still reboot the device to start the existing application. 

What causes the fail? Do you have any error log or message? Could you provide the logs from nRF Connect and a sniffer trace? Are you using SDK v15.2?

-Amanda H.

[Julien]

In fact, nothing cause the fail.

To explain more, the dfu is realized by an other nrf52 device. It's a central ble who update the peripheral.

The process is a bit long (around 1min30) and the two device could be moving. So a loss of connection is possible during an update.

And for me during an single-bank update, the application is not preserved, if I read your link, if we fail the update, we restart in bootloader without application. It's for that we use a dual-bank update.

The dual-bank update work well except for the first dfu, if I cause an error intentionally, the device restart the bootloader, but it's broke then.

I make the cmd "nrfjprog --readregs" to know where the device is blocked.

And i have this answer 

R0:   0xFFFFFFFF
R1:   0xFFFFFFFF
R2:   0x00024D39
R3:   0x00026000
R4:   0x00001000
R5:   0x20001378
R6:   0x00024D39
R7:   0x00000000
R8:   0xFFFFFFFF
R9:   0x00000000
R10:  0x00000000
R11:  0x00000000
R12:  0x40000614
SP:   0x20001378
LR:   0xFFFFFFFF
PC:   0x00024D36
xPSR: 0x61000000
MSP:  0x20001378
PSP:  0x00000000

So for me the device is blocked in the sofdevice.

Julien f

[Amanda Hsieh]

Hi, 

The staffing is reduced during easter due to holidays and I will be gone this week, but I will be back Tuesday next week and will look at your ticket then.

-Amanda H.

[Amanda Hsieh]

Hi,

Julien said:

if I cause an error intentionally, the device restart the bootloader, but it's broke then.

How did you cause an error? Could you provide the detail? 

-Amanda H.

[Julien]

To cause an error, i just switched off my central during the DFU process 

[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