Mesh DFU transfer self hosted

[SirBuhi]

Hi there,

The Mesh DFU on my project is so far working, but as stated on the bootloader read me, the process need to initiated and crontrolled by another extrenal entity.

Is there a possibility for a self hosted DFU transfer?

In a first stage the new firmware might be storred in an external flash and the process might be initiated by a button or later via an command from the internet.

Background:

The mesh network will be placed somewhere in the world with an LTE connection. The new firmware will be loaded and initiated therefore from the internet.

Cheers,

SirBuhi

[AHaug]

Hi,

This might be possible, but unfortunately we don't have anything but pointers to you for how to do this. If you're controlling the procedure from another MCU, we have the protocol description here: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.meshsdk.v5.0.0%2Fmd_doc_user_guide_modules_dfu_protocol.html.

Are you expecting to control the DFU procedure from a source that is going to be updated itself, or are you doing this from the LTE-device (for instance a nRF91-based device)?

Kind regards,
Andreas

[SirBuhi]

Dear Andreas,

Unfortunately the LTE-device is given and I can't use its MCU.

Therefore the idea is to control the mesh DFU from a source that is going to be updated itself during the background DFU operation.

At the moment I'm thinking about using the nRF Util Tool for the DevicePage, Initial Flashing and creation of the zip file for the Mesh DFU process. The three necessary files will then be loaded into memory where the nRF52840 can access them.

The control of the DFU process will then be implemented in the application part.

Do you think that it will be possible?

Cheers,

SirBuhi

[AHaug]

Hi,

I will have to do some more investigation throughout the coming week, but I don't think we have any other information/resources than what I've supplied here for how to do this. I'll get back to you as soon as I know if I can give you some more information

Kind regards,
Andreas

[AHaug]

Hi,

Apologies for the delayed response, I've been out of office last week due to a fever.

Unfortunately I've not found any other resources, samples or guides for how to create this specific DFU variation than the Mesh DFU sample with its propriatary mesh dfu protocol documentation. The challenges that I've mentioned in my earlier reply are still valid, but the Mesh team commented that the procedure you suggested earlier sounds like the correct way to move forward.

Kind regards,
Andreas

[SirBuhi]

Hi there,

 

I’m currently struggling a bit with my self hosted mesh dfu.

 

Currently I can do a self hosted DFU via the UART. Which means that I have the code for the deployment running in the application and send it out over the app uart. The TX pin of the app uart is physically connected to the RX of the serial interface. Like that all is running as wished.

 

Since that is not the preferred option, I’m looking for an integrated version, without using the UART part.

 

For that I do send my DFU data directly to the nrf_mesh_dfu_rx() function. Somewhere down the line of the nrf_mesh_dfu_rx() function the time_sch_reschedule() function of the timer_schedule.c file gets called and in there the bearer_event_in_correct_irq_priority(). Where somehow the problem lies.

 

Case Mesh Init IRQ Priority: NRF_MESH_IRQ_PRIORITY_LOWEST

If I initialize the mesh with the priority level NRF_MESH_IRQ_PRIORITY_LOWEST the DFU can be received via UART connection (host) and BLE connection (target). However, I get an mesh error while calling the nrf_mesh_dfu_rx() function to inject data.

 

Case Mesh Init IRQ Priority: NRF_MESH_IRQ_PRIORITY_THREAD

If the mesh is initialized with the priority level NRF_MESH_IRQ_PRIORITY_THREAD I can send now data to the nrf_mesh_dfu_rx() function and the host board updates itself. But, the DFU data does not get transmitted to the other boards over BLE. As well as it is not possible anymore to update the board via the Serial UART interface. It looks for me, as this settings changes more than wished.

 

Can you maybe give me a hint in which direction to search, to get it running?

 

Cheers,

SirBuhi

[AHaug]

Hi,

I will look into it! However we're going into the Christmas holiday period here in Norway now so I will be on and off work until the first week of January, so the response time might be a bit longer than usual. 

I hope this does not cause too much of an issue for you.

Kind regards,
Andreas

[AHaug]

Hi SirBuhi, 

Apologies for the long response time. It took some time to find the correct people who might've had some input on this. Unfortunately I haven't uncovered any good news..

SirBuhi said:

Yes, Version "nRF5 SDK for Mesh v5.0.0" is the one that we already have implemented in the project and would like to use now.

First of I would like to move back to this statement in the early days of this case and more explicitly state something that I've only implied previously, which is that we typically recommend new(er) projects to be developed with nRF Connect SDK instead of nRF5 SDK due to support available for the SDKs. I know that SDK5 for Mesh is the only one that currently supports DFU, but you might be better of with nRF Connect SDK instead nonetheless. You're however free to use nRF5 SDK for Mesh if that is what you want

As for your latest questions: As I've stated we think that this is possible, and that the nrfutil source code be a good source to follow, but as you're going quite out of the scope of how DFU is intended to be used with Bluetooth Mesh, we're limited to how we can support this other than having a look at nrfutil: https://github.com/NordicSemiconductor/pc-nrfutil

Again, apologies for the little help we're able to give you with this project.

Kind regards,
Andreas