nRF Mesh DFU example vs precompiled bootloader

RE: nRF Mesh DFU example vs precompiled bootloader

AndreasF — Fri, 12 Oct 2018 11:14:29 GMT

Hi again.

The serial interface protocol is a sub protocol for the serial protocol. All data transfered is done with the DFU-data-opcode in the Mesh serial protocol.

There isn't a lot of documentation on the serial format for DFU, but you can look at the packet here and the message sequence chart here. I think that the cleanest reference for the serial interface is found in the dfu_transport_mesh.py script

- Andreas

RE: nRF Mesh DFU example vs precompiled bootloader

gsegment — Fri, 12 Oct 2018 09:11:55 GMT

Thanks,

Serial interface protocol for bootloader differs from serial protocol used in mesh application? So host uart controller should supprot both protocols to be able to transfer DFU updates? Where I can read bootloader serial interface documentation? I found only short descriptions and pyaci scripts that operates with serial interface, but no documentation or detailed description.

RE: nRF Mesh DFU example vs precompiled bootloader

AndreasF — Fri, 12 Oct 2018 07:56:35 GMT

Hi again.

Nordic's DFU is a Nordic proprietary feature which follows the Bluetooth Mesh protocol.

You can have a unit that only runs bootloader, which can receive application and SoftDevice from DFU.

It is possible to update a local unit, this unit will however broadcast this update.

Since the TX does not know the number of units that receive the update, there is no naive method to check this in the protocol. The units do have recovery-mechanisms to handle lost packets, but the units must be checked with the normal mesh (Bluetooth Mesh) protocol to assure that the devices are updated.

- Andreas

RE: nRF Mesh DFU example vs precompiled bootloader

gsegment — Thu, 11 Oct 2018 12:54:57 GMT

Thanks for explanation,

So, the Nordic's DFU is not a part of Bluetooth Mesh protocol? I am confused now, correct me if I am wrong: DFU process based on broadcasting and relaying custom OpenMesh messages format (not Bluetooth Mesh), right?
I read that Bootloader can operate separately. So, when it is running, can bootloader relay/accept DFU messages (situation, when there is no application and softdevice flashed - only bootloader)?
Can bootloader update its own application and softdevice via serial bootloader OpenMesh interface? It is not clear for me. The situation is when I have device with bootloader only, and this device is connected to the host controller via serial interface, and host wants to update/load nrf52 firmware, not translating to other mesh devices.
How DFU initiator will determine that all devices receive full firmware? Because, if it is simple broadcasting OpenMesh packets, then there is no reliable method to get update status.

RE: nRF Mesh DFU example vs precompiled bootloader

AndreasF — Thu, 11 Oct 2018 08:07:08 GMT

Hi.

Yes. \examples\dfu is an example of a device firmware update application.

\mesh\bootloader uses rbc_mesh_ methods because the bootloader is a port of the bootloader from OpenMesh without any major modfications. The DFU in mesh operates in the OpenMesh-message format. The bootloader does support rbc_mesh_ methods, but it can also receive and relay DFU messages over the mesh, and an interface application can request DFU-support when an application is running.

- Andreas

RE: nRF Mesh DFU example vs precompiled bootloader

gsegment — Wed, 10 Oct 2018 14:59:51 GMT

Hi,

Am I right that \examples\dfu should be a part of application to be able to receive firmware updates? It receives and stores firmware update packets and after that calls bootloader to check and switch application, correct? I am trying understand the purpose of \example\dfu.

I can't undestand why \mesh\bootloader is using rbc_mesh_ methods, as I know these methods are made for OpenMesh and not for Bluetooth Mesh. What is the puprose of using rbc_ stuff? I thougth that this bootloader handle only application switching and over serial firmware update.

RE: nRF Mesh DFU example vs precompiled bootloader

AndreasF — Mon, 08 Oct 2018 12:24:01 GMT

Hi.

The files inside the folder nrf5_SDK_for_Mesh_v2.2.0_src\bin\bootloader is just precompiled .hex files with different configurations for different boards. All files in the nrf5_SDK_for_Mesh_v2.2.0_src\bin folder are precompiled.

The folder nrf5_SDK_for_Mesh_v2.2.0_src\examples\dfu contains a device firmware update example, not the bootloader.

If you want to build your own bootloader you should look in the nrf5_SDK_for_Mesh_v2.2.0_src\mesh\bootloader folder.

If you open the README.md file, you can read the following about creating your own bootloader:

## Requirements
See [The toolchain document](@ref md_doc_getting_started_how_to_toolchain) for the required tools
for building and using the bootloader. Pre-compiled variants of the bootloader are available in
the `bin/` folder. Building the bootloader is only supported with the CMake build system and can
be enabled with the `BUILD_BOOTLOADER` CMake option. Be aware that the bootloader must be built
with `CMAKE_BUILD_TYPE` equal to `MinSizeRel` for it to fit within its flash size requirement.

As you can read here, you have to use CMake to build it, and you have to modifiy the files you require found in the nrf5_SDK_for_Mesh_v2.2.0_src\mesh\bootloader\src and nrf5_SDK_for_Mesh_v2.2.0_src\mesh\bootloader\include folders.

There is some documentation about using CMake here.

- Andreas