This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

DFU over BLE from application using buttonless, background or not possible?

Hi,

We area working on an iOS Application using nRF Toolbox as a reference. We are currently implementing OTA DFU over BLE and are able to update the nRF52 devKit from the iOS application by using the DFU Secure Bootloader project.

On the other hand we have added the Device Information Service (0x180A) to our devKit/firmware software to obtain information such as Hardware Revision and Firmware Revision.

We are now trying to implement the following use case:

1st step: Have the DFU mode always available (as a GATT service?) together with the rest of our services: DIS (this one specially), Health Thermometer, Proximity, etc.

2nd step: when the user selects the 'update DFU' feature in the iOS app, obtain the HW and FW revision numbers from the DIS

3rd step: Obtain the latest firmware package from a backend

4th step: update the devKit's firmware without having to enter DFU mode

We are already performing 2nd and 3rd steps but we are not sure 1st  and 4th make sense

Questions:

Q1) Is it possible to have DFU always available, or the alternative we have is to enter in DFU mode (using the buttonless approach for example) after obtaining the firmware from backend (3rd step)?

Q2) Instead of using the DIS should we instead obtain the HW and FW versions using a different approach: for example by sending the corresponding DFU requests:

0x0A -> Hardware Version

0x0B -> Firmware Version

when the device is in DFU Mode?

  • Hi 

    If I understand you correctly you want to run a DFU update in the background while still running the application?

    My colleague Vidar discussed this in an earlier thread.

    This is technically possible, but it has many drawbacks compared to doing DFU the normal way: 

    1) The DFU update will be much slower, since it has to be run while the application is active

    2) You will only be able to update the application, not the SoftDevice or bootloader

    3) It will limit how large the application can be, since you have to reserve dual banks for the application. On a device like the nRF52840 this might be OK, but on the nRF52832 you have much less flash available. 

    4) It will be much more complex to implement and test, since there is always a risk that running DFU and application side by side could lead to reliability issues. 

    I would strongly consider just doing DFU the normal way instead. Normally DFU is not something that needs to be run very often, and we have worked to optimized the speed of DFU in recent updates to ensure the user won't have to wait too long for the DFU to complete. 

    Best regards
    Torbjørn 

Related