• State Not Answered
  • +1 person also asked this people also asked this
  • Replies 5 replies
  • Subscribers 62 subscribers
  • Views 1303 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 222937
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Firmware update without IPv6 and TFTP

Mike_K
Some Examples discuss background DFU from application level, but those require bringing in IPv6 stack and TFTP client. Since we are planning to integrate DFU of our device with a mobile application, this has 2 undesired side effects:
1. On the device itself IPv6 and TFTP would compete with our application code for space (I assume IP stack is not at all negligible in size)
2. Going this route would require our mobile application to support IP over BLE (not sure at this point if it's trivial or not, but seems like a fair task... Also a TFTP server would be required. Again, probably not hard to come by, but still, a task.)

 So, is it possible for the background DFU / TFTP solution to be changed, so neither IPv6 nor TFTP are required -- we get the image onto the file system over our own BLE messaging mechanism, and then we feed the finished image (that we stored on the filesystem) to the background DFU library, that writes it to the proper location.
Or, is there a whole different approach that you would suggest I resort to?
Using SDK nRF5_SDK_15.2.0_9412b96 on nRF52 development kit. S132 Softdevice.
Thanks!
  • 0

    Hi,

    The nRF5 SDK does not have a generic background DFU implementation for BLE. You could probably use parts of the existing bootloader, splitting it so that transport and pre-validation is part of the application, and make a slim bootloader that only does copying and post validation. You might also find some inspiration in the SDK for Thread and ZigBee in this case, as that has background DFU for ZigBee. This will require quite a bit of effort, though.

  • 0 in reply to Einar Thorsrud

    Ok... so, if background DFU is out as a solution for BLE, what is the best example to follow if I would like to download the new image as a part of the application, and then hand it over to the infrastructure to have it written?
    Or is such a scenario not supported at all? And if so, which is the best-supported traditional way of architecting and implementing a DFU over BLE on nRF5?

    Thanks

  • 0 in reply to Mike_K

    Hi,

    The nRF5 SDK has a very well tested bootloader example that handles OTA DFU. If background DFU is not a requirement for you, then I suggest you go for that. See bootloader example and bootloader modules documentation for details. This is a complete solution delivered by us that requires virtually no effort on your side.

    Regarding background DFU I just recommend you refer to the examples I pointed to. This will require a substantial amount of development work on your side.

  • 0 in reply to Einar Thorsrud

    Thanks for the reply. I will choose the easier way, if possible, as I'm under a time crunch.

    A couple more questions.

    1. This description requires that the device is rebooted with a button press held, for it to boot into a bootloader which could then accept the new image.

    Instead, is there a way for the on-device application, once it's been BLE-messaged that "new image is coming" to reboot the device into the bootloader DFU-mode without the need to hold any button? There are no physical buttons on my device.

    2. Is there either (or hopefully both):

    A: Example source code of Android application that would provide the new image to the bootloader, possibly with ready Android libraries to link into our application, that would take care of the transfer?

    B: Detailed documentation on the communications protocol between Android smartphone and the bootloader? 

    3. Is it possible to have the application save the image off into the filesystem, and have bootloader access  and write it, once the system has been rebooted, or is this scenario also not supported?

  • 0 in reply to Mike_K

    Hi,

    1. The bootloader can be triggered in many ways. One of the options is by including a DFU service in the application, which can then be used to enter bootloader DFU mode. This is demonstrated by the Buttonless DFU Template Application.

    2A. We provide DFU libraries for both iOS and Android. You use the nRF Toolbox app as a reference for how it is used.

    2B. The communication protocol is not Android specific, as this is a protocol defined by us that is common regardless of which DFU master you use. There is no need for you to focus on the protocol as we provide libraries for Android as well. You can find it documented her, though.

    3. No. That is the "background DFU" principle, which is not supported. When starting a upgrade, the application will reset in to the bootloader and it will handle the transport of the DFU image as well as validation and activation.

    Please note that DFU is quite complex so I recommend you spend a good amount of time reading the documentation and playing with the SDK examples.

Related