Any way for nrfConnect for desktop to dfu sd_bl + app without reset or disconnect?

[Anthony Ambuehl]

I have implement an in-app DFU procedure based  on Nordic's dfu ble service.   The images are saved into external norflash and then control is passed to a bootloader which validates and copies the data into internal flash.  

When performing a softdevice_bootloader and application update, I would like to transfer all images without disconnecting.  My reasoning for this is to avoid accidentally combining a softdevice_bootloader update with a different application update.   Currently the nrfConnect app waits for a disconnect before sending the application image. This is problematic because after the connection is re-established there is no way to be know whether this is a new DFU procedure with only an application or the continuation of the previous DFU.

 Is there anyway to signal the nrfConnect app to proceed with the application image without disconnecting?

[bjorn-spockeli]

Hi Anthony, 

My reasoning for this is to avoid accidentally combining a softdevice_bootloader update with a different application update. 

 Are you concerned about compatibility issues or an attacker ? The application package still needs to be signed with the correct private key, have the correct application version and  the correct SD ID set with the --sd-req option so I dont really see how one accidentally updates the wrong application. 

If you use the bond sharing feature of the bootloader then you can ensure that its only the DFU controller, i.e. Android or iOS device that initiated the DFU procedure that can reconnect to the nRF device after the SD+BL update. 

 

Is there anyway to signal the nrfConnect app to proceed with the application image without disconnecting?

 Its not the nRF Connect application that disconnects, its the bootloader that does this on the NRF_DFU_EVT_DFU_COMPLETED event, see the dfu_observer() function in nrf_dfu.c

However, simply commenting out the call to nrf_dfu_transports_close() will break the DFU procedure on the nRF Connect application side, which expects a disconnect. 

Best regards

Bjørn

[Anthony Ambuehl]

My main concern is about compatibility issues.  Since the sd+bl image is stored in external flash, it persists forever, and could be present on a simple application update at any point in the future.  

Although this seems like a rare/impossible case in the real world, its quite easy to occur during automated testing that might include for example an interrupted sd+bl/applicatoin DFU followed by a simple application DFU.   

Although the nRFconnect is not disconnecting, it is waiting for the application to disconnect and will error out with a timeout if the connection doesn't end.  I'm looking for someway to tell the nrfConnect it can proceed with the application transfer, preferable without a disconnect.

[bjorn-spockeli]

Hi Anthony, 

Anthony Ambuehl said:

My main concern is about compatibility issues.  Since the sd+bl image is stored in external flash, it persists forever, and could be present on a simple application update at any point in the future

If the SD+BL image is stored in external flash you still need to perform the actual update by copying this into the internal flash of the nRF52. The softdevice ID check is done against the SoftDevice that is present in the nRF52. So a received SD+BL update should always be "activated" before performing a application update to prevent the compatibility issue you are referring to. 

In the default BLE  Bootloader example we do the following: 

When a new SD+BL update is received it is postvalidated, where we check the integrity of the received firmware by comparing CRCs and then we also check if the SoftDevice update is a major update, i.e we compare the version number of the new SD vs the old. If its a major update we invalidate the existing application as it is incompatible and then perform the update. After the SD+BL update, the only way you can upload a incompatible application is if you explicitly set the incorrect SD ID when generating the DFU package.   See the postvalidate_sd_bl() function in nrf_dfu_validation.c in the bootloader project. 

 I do not know how you have implemented the in-app DFU procedure, but if you receive the SD+BL image first and then store this in external flash, then you can apply this update before starting the application transfer. You can also extract the SD ID of the SoftDevice present in the external flash and compare this against the --sd-req value in the init packet of the application image in the prevalidation step, that way you can check the compatibility of the application against the SD present in the nRF52s internal flash and the SoftDevice present in external flash. 

Best regards

Bjørn

[Anthony Ambuehl]

You don't need to explain about copying the external flash into internal flash.  I already have this working.  I'm only try to address the unusual corner case specifically in this ticket.

Applying the sd+bl update without already having the corresponding application would leave the device without an application in the case of a single bank update.  Since the old application may incompatible with the new softdevice, its not acceptable to use the old application with the new softdevice..

To prevent this, I need to download both the new application and the sd+bl image into external flash before doing any updates.  This creates the scenario where first, the sd+bl image is downloaded and then first dfu procedure is aborted and then a second unrelated application only dfu is started which unintinentionally gets combined with the aborted sd+bl dfu.  Unfortunately an aborted DFU that occurs while the device is disconnected is undetectable to the application.

The main requirement is that a dfu never leave the device unable to provide the core functionality therefore we cannot utilize bootloader BLE update since the core functionality would not be included in the bootloader.  I have had many support issues with multiple clients in the past where their customers considered the device "bricked" when in reality it was in the bootloader.  This is unacceptable for the type of device I am now working on.

[Anthony Ambuehl]

I now realized that the init command for application will include the sd requirement which can be checked against the stored sd+bl image before loading.    I will implement logic to perform the sd requirement validation between the stored application and the stored sd+bl image, and erase the sd+bl image if it does not meet the requirements of the application.

[bjorn-spockeli]

Yes, either invalidating the application image present on the nRF or invalidating/erasing the softdevice+bl image in external flash based on the --sd-req of the application image init packet or  the sd ID of the SD in external flash should work.

Best regards

Bjørn