Ability to restart DFU when interrupted while in DFUTarg

[QuentinFarizon]

Sometimes during a DFU update, the NRF52811 can stay in bootloader mode (seen with name DFUTarg and mac_address equal tomac_address+1).
I am on Softdevice 16.0
I'm using the https://github.com/NordicSemiconductor/Android-DFU-Library.

To be able to resolve this situation, I imagine that it would be possible for this DFU library to recognize a previous DFU process failed, and restart the DFU process from here.

I have tried setting initiator.setNumberOfRetries(1) but it did not help.

Is there something I'm missing ? How can I implement this myself ? As I can connect to the mac_address+1, is there a command I can send to make it restart on normal mode ?

[Einar Thorsrud]

Hi,

There is not DFU command to exit DFU and reset the application. However, the bootloader has a timeout which is configured by NRF_BL_DFU_INACTIVITY_TIMEOUT_MS in the bootloader's sdk_config.h. This is set to 2 minutes (120000 ms) in most bootloader examples in SDK 16. So if there are more than 2 minutes of inactivity the bootloader will start the app if a valid app is present. If no valid app is present (typically if having started a single bank update), the only way to recover is to perform a successful DFU update.

[QuentinFarizon]

Indeed, I do not have NRF_BL_DFU_INACTIVITY_TIMEOUT_MS set.

When you say "the only way to recover is to perform a successful DFU update." => how can we perform a successfulDFU update when in this state ?

[Einar Thorsrud]

Hi,

QuentinFarizon said:

When you say "the only way to recover is to perform a successful DFU update." => how can we perform a successfulDFU update when in this state ?

That depends on which state the device is in, which is not entirely clear to me. What DFU master are you using? If you are testing for nRF Connect, then you can get a log which may give some relevant information. Any other information about when/how update fails will also be useful.

[QuentinFarizon]

I'm using an ionic library that uses https://github.com/NordicSemiconductor/Android-DFU-Library under the hood.

I'm not exactly encountering an issue with real uses, but I try to see if the DFU process is resistant to connection loss, loss of power, ... before allowing users to perform DFu themselves on the field.

I will try with NRF_BL_DFU_INACTIVITY_TIMEOUT_MS, if there is a loss of power during upload, it should restart with the previous application right ? 

[QuentinFarizon]

But I'll still have the issue of my previously distributed PCBs. In the state they are when interrupted, they are on bootloader on DFUTarg, but previous application should still be there. How can I just restart it on the previous application ?

[Einar Thorsrud]

Hi,

QuentinFarizon said:

I'm using an ionic library that uses https://github.com/NordicSemiconductor/Android-DFU-Library under the hood.

I see. Then I suggest you test with nRF Connect just to obtain the the log if needed.

QuentinFarizon said:

I'm not exactly encountering an issue with real uses, but I try to see if the DFU process is resistant to connection loss, loss of power, ... before allowing users to perform DFu themselves on the field.

Then it would also be useful to test with the debug bootloader with RTT logging to understand what happens on the bootloader whenever you see an issue of some sort.

QuentinFarizon said:

I will try with NRF_BL_DFU_INACTIVITY_TIMEOUT_MS, if there is a loss of power during upload, it should restart with the previous application right ? 

Yes. But that of course depends on the presence of a valid application. If the existing application has been removed allready because of a started single bank update of the app or SoftDevice/BL update, then there will not be any valid app to boot.

[QuentinFarizon]

Even withtout a valid app to boot, the bootloader should be OK. Is it not possible to perform a new DFU process, with the bootloader already in DFU mode ?

[Einar Thorsrud]

QuentinFarizon said:

Even withtout a valid app to boot, the bootloader should be OK.

Yes.

QuentinFarizon said:

Is it not possible to perform a new DFU process, with the bootloader already in DFU mode ?

That should not be any problem. (Though it seems like it is in your test, which is why I suggested to get logs to understand what is going on.)

[QuentinFarizon]

What do you mean by "not a problem" ? How does it work in practice ?
When I'm starting a DFU again, it simpy tries to connect to the adress mac, and fails because in DFU targ it has mac_address +1 
Is it supposed to also try to mac_address + 1  ? Or am I supposed to laucnh DFU on mac_address +1 when it fails on mac_address ?

[Einar Thorsrud]

Hi,

QuentinFarizon said:

What do you mean by "not a problem" ? How does it work in practice ?

I mean you can connect again and try to update. There should not be any problems with that. Is there? 

QuentinFarizon said:

Is it supposed to also try to mac_address + 1  ?

Yes, that is intentional. If you use the same old address and is bonded, the phone will attempt to encrypt the link. If you do not share bonding information between the app and bootloader, encryption will fail and the phone will disconnect. Therefor, the bootloader always increments the MAC address by 1 when you use a bootloader without bonding. (You should not take this as an incentive to use bonding with the bootloader unless you have a good reason to do so, as that introduces other problems, particularly if the bond is deleted on the phone after entering DFU mode on the device.).

QuentinFarizon said:

Or am I supposed to laucnh DFU on mac_address +1 when it fails on mac_address ?

Yes. If not using bonding in the bootloader, you would have the "normal" address when in the application, so this is where you write to the DFU service to make the device start the bootloader and enter DFU mode. After that, you always need to use address + 1 in this case.

[QuentinFarizon]

Thank you for your kind help and guidance.

DFU process was able to proceed again successfuly, after having being able to connect to the PCB in bootloader "DfuTarg" mode. My code that scanned before connecting was still filtering by a custom service that was not available in bootloader mode.