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

[Julien]

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

[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.

[Julien]

If a understand, bank_current = 0x01 means that the bootloader will check if a valid app is present in bank1, if not, it's started the bank0

Am I rigth?

[Julien]

I don't understand why the bank_current stay to 0x01 once a dfu is realized. 

In looking  Dual bank example, for me, once the bank1 is validate or not, the bank0 should be selected again.

[Julien]

The device doesn't not stay in DFU Targ at the init because a older dev has bypass that at the init. There is a way to flash a valid application with nrfjprog ? 

[Julien]

Okay, i think i understood.

I need to generate my settings with "nfrutil settings generate" and then merge the hex with my SD+BOOT+APP in order to have valid application directly.