Both on android and IOS stops DFU process if device reports busy using Nordic DFU_MCUMGR lib

[Tommy F Kristensen]

I have been experience that the if the device under a DFU process reports the error BUSY, because the external flash on the device is used for fileaccess the DFU process from the app fails and stops.

I have to resytart the whole process, it seems that the lib does not handle that it can get a busy back and then retry sending the package again.

Im using nRF54L15 and SDK3.0.2 and latest lib for uploading DFU from app

Link to lib used

https://github.com/NordicSemiconductor/Android-nRF-Connect-Device-Manager

I haven tried to wrtie a handler to handle the BUSY, but it need to restart the whole process each time and cannot resume if it get one BUSY.

I the busy from flashin in the verification part Error 257 is reported,, and the device does not seems to be recoverable from that state only with a reset

Best Regards

Tommy F Kristensen

[Vidar Berg]

Hi Tommy, 

I have reached out to our app developers to see if they have any suggestions to this. Will let you know as soon as I have heard back from them.

Best regards,

Vidar

[Tommy F Kristensen]

Hi Vidar 

Thanks for your answer

I have been strugling a lot this to understand what did happend.

By default the FirmwareUpgradeController, does not handle errorcodes like 0x10 (BUSY) from target, it calls onUpgradeFailed. We did implement a retry if the device did report BUSY. This works ok the first 10 times, then the error 257 comes(This error is not coming from the target, but from the Android system(insufficient resources)).  

override fun onUpgradeFailed(state: FirmwareUpgradeManager.State?, error: McuMgrException?) {
    logger.error(TAG, "(BT) DFU failed: $state, error: $error")
    firmwareUpgradeController = null

    if (error != null &&
       error.code.value() == 10 &&
 (state == FirmwareUpgradeManager.State.VALIDATE || state == FirmwareUpgradeManager.State.UPLOAD) &&
 retryAttempt < MAX_BUSY_RETRIES
 ) {
 scheduleBusyRetry()
 return
 }


In scheduleBusyRetry() we basically reastarted a new dfu, and it resumes the DFU process perfectly 10 times,
but the issue was that the transport was not reused doing a restart of the the DFU process and a new instance was created each time.

transport = McuMgrBleTransport(context, bluetoothDevice.bluetoothDevice)

val dfuManager = FirmwareUpgradeManager(transport, dfuCallback)
...
It started working after we did start to reuse the transport,
but it was quite hard to figure out cause the only error code we got was error 257,
Fix:
Done Once on dfustart
 lastDevice = bluetoothDevice.bluetoothDevice
 lasttransport = McuMgrBleTransport(context, lastDevice!!)
 ...
Done on each retry
val dfuManager = FirmwareUpgradeManager(lasttransport , dfuCallback)
....
It would be nice if the library had implemented some error handling retry on Busy and Timeout from the taget,
not ending in a callback upgradefailed.
This error is seen on both Android and IOS

Best Regards
Tommy F Kristensen

[Tommy F Kristensen]

Hi Alexander

Thanks for your answer

we are using the external flash for both DFU and external filesystem and occasinally it can be BUSY, so thats why we need handle it :-)

Best Regards

Tommy F Kristensen

[Tommy F Kristensen]

Hi Alexander

Are you planning to make some error handling inside the library. We have handled in our app firmware on both platforms(IOS/Android) in the callback onUpgradeFailed, where we have added a retry logic.

But I think that a busy should not lead to onUpgradeFailed on first error.

Best Regards

Tommy F Kristensen

 

[Aleksander Nowakowski]

Hi, yes, we will handle this status in the library. We will soon switch to nRF Connect Device Manager project.

[Dinesh Harjani]

Hi Tommy. Dinesh here, I maintain the iOS DFU Library (McuMgr).

Are you guys able to pull from main branch and test a possible fix for this? Or do you need a release? This is so I can push a possible fix, so you guys can test whether it works for you or not, and provide some feedback without the need for a release without knowing for sure if it works out.

Thanks.

[Dinesh Harjani]

Bit of follow-up - there's a possible fix in the main branch. Let me know when you've tested it.