Mesh OTA DFU: How do you send the .zip file containing the DFU from Android OTA to the mesh?

[BlueMike]

Dear Mesh Experts,
 
Allow me to briefly explain the project:

1. The firmware contains a generic level server model and the code from the mesh DFU example. It is running on an nRF52832 with SoftDevice 7.2.0, a matching bootloader and device page. (Please note that we're talking about a BLE mesh.)
2. The app is written in Flutter. Provisioning, unprovisioning, connecting, getting and setting values... It all works fine.
3. A DFU-zip-file containing an updated application has been created as explained at Configuring and performing DFU over Mesh.

So far, so good. The question is, what needs to be done to perform the background firmware update? The workflow I'd like to implement looks roughly like this:

1. The Flutter app connects through a proxy node to the mesh.
2. The app uploads the DFU-zip-file OTA to the proxy node it is connected to.
3. The proxy node just forwards the DFU-zip-file into the mesh.
4. All matching nodes (which includes the sending proxy node) receive the DFU-zip-file from the mesh and happily update themself.

Sounds simple, the questions are:

• How do you send the DFU zip file from the app to the connected proxy node (OTA)?
• Once the proxy node received some part of the data, how do you broadcast it into the mesh?
• Or..., do you have any better ideas how to implement it?

 Your advise is very much appreciated. Thank you, and all the best for 2021!

[Amanda Hsieh]

Hi, 

I suggest you have a look at Configuring and performing DFU over Mesh and Mesh DFU protocol from the infocenter. There is an example of using BLE DFU (from nRF5 SDK) with an nRF5 SDK for Mesh example (but without the mesh DFU solution): Configuring DFU over BLE using the LPN example.

Notice that we are entering the Christmas and New Year holidays and will have reduced staff, please expect delayed responses until after January 4th. Sorry for the inconvenience.

-Amanda H.

[BlueMike]

Hi Amanda,
 
thanks for your help in that matter. Unfortunately the provided links ain't very helpful, so I've updated the original post to provide more details.

Again, thanks for  your help and all the best for 2021.

[Amanda Hsieh]

Hi,

1. We do not send the DFU zip file to the proxy node at all. The zip archive is sent via serial interface(UART) to the node that is switched into bootloader. For more details see the documentation Transferring the DFU archive over serial with nRF Util. DFU protocol is the proprietary protocol that does not share any fields with Bluetooth Mesh packets. That means the proxy server node cannot retransmit DFU data via proxy protocol using existing(from specification) GATT characteristics.
2. Some node that supports DFU receives DFU data (proprietary AD type and format) via ADV bearer will rebroadcast it to the others via ADV bearer as well. GATT bearer(it is used for proxy client-server communication) is not used for this. 
3. To be able to start and to upload DFU zip archive from the proxy client (Flutter app in your case) we recommend using custom GATT characteristic and implement a handler for this characteristic that will redirect data from it to ADV channels with DFU AD type. Or as an alternative to extend the proxy protocol with custom PDU type with tunneling DFU protocol via it.
   or as the simpliest way to use DFU over BLE instead of Bluetooth Mesh DFU.  It allows using GATT communication from the box. As Configuring DFU over BLE using the LPN example.

-Amanda H.

[BlueMike]

Hello Amanda,  
 
Thanks for your help in that matter. 

We recommend using custom GATT characteristic ... that will redirect data from it to ADV channels with DFU AD type.
Or as an alternative to extend the proxy protocol with custom PDU type.

Which of those two approaches would be less work to implement? Which would require less memory?

Can you please share some details or examples about how to implement those two approaches?  
 
Thank you,
Michael.
 

[Amanda Hsieh]

Hi Michael, 

Both of them are not standard ones. The requested feature is not supported by SDK. Obviously, there are no examples for them. 

We provided an example of how to use BLE DFU and I provided the link already. From my point of view, it is the better solution for him but it is not suitable for the customer for some reason.

The suggested ways of implementation require appropriate knowledge. 

If you prefer to use custom GATT characteristics it is better to take a look at SoftDevice BLE GATT API and documentation.

Advantage: It does not require changing the BLE MESH source code and could be done as part of an application.

Disadvantage: it requires learning what SoftDevice and GATT are and how to use them.

 

If you prefer to extend the proxy protocol it is better to read Mesh spec related to Proxy and take a look at stack proxy implementation './mesh/gatt/src/proxy.c'. Proxy protocol parser starts in function `rx_handle`.

Advantage: it reuses GATT implementation from the BLE MESH stack

Disadvantage: it requires changing the proxy implementation

There are no ready or semi-ready good solutions for that. Both require quite a deep understanding of what and how to do and include a significant amount of work. 

-Amanda H.

[BlueMike]

Hi Amanda,

That's interesting. So, to summarize the current state of the Mesh DFU:

1. To use Mesh DFU, the new firmware must be provided by serial line.
2. There is currently no api to provide a new firmware for a Mesh DFU through a proxy node.
3. For pure OTA DFU, BLE is basically the only options.

It sounds like the use cases for Mesh DFU are rather limited...
Anyway, thanks for the detailed clarifications. I'll migrate to BLE DFU.