Mesh DFU Example - PROVISIONING into the Mesh network!?

[EAn]

Greetings!

I am using the SDK Mesh 3.1.0 and Softdevice 6.1.0 with the nRF52840 Dev kit: (PCA10056)

I'm having some issues with the example provided in $MESH_SDK/examples/dfu/... I followed the tutorial you have here: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.meshsdk.v3.1.0%2Fmd_doc_libraries_dfu_dfu_quick_start.html with two devkits, one loaded with the DFU example I just refered, which is connected via serial and which would distribute the firmware update to the other node which is loaded with the light_switch firmware.

I have provisioned the light switch, but there seems to be no way to provision the devkit with the dfu-example firmware, so, how can it distribute the packages within the mesh network if it isn't even provisioned to the same network!? What am I missing here?

Thank you for your assistance.

Regards,

//EA

[Hung Bui]

Hi EAn, 

The DFU node can still be provisioned as a normal node if the provisionee role is implemented. 

The DFU role is not related to BLE Mesh. DFU mesh process is actually running on top of OpenMesh instead of BLE Mesh. So it's a very basic proprietary mesh protocol that we used for DFU. 

In the future DFU mesh may be integrated into BLE Mesh, but it's not in the spec yet. 

There is no provisioning needed for OpenMesh .

[EAn]

Hi Hung Bui,

Thank you very much for the informative reply. I thought so, but I can't get any other node to be updated except for the one distributing the firmware... I was trying to understand what might have gone wrong...

So basically if the device page shares the same app ID and a lower version than the one issued by DFU, as well as the same company ID and public key, the firmware update should be made even if the devices are in different bluetooth mesh networks, because this operates in a different network type:OpenMesh.... Right?

Well, I have changed my Mesh Stack no enable the CODED PHY  to increase range. Does this interfere with the DFU-OTA OpenMesh?

Thank you so much for your reply!

Best,

//EA

[Hung Bui]

Yes, it would. Note that even though the network is different but the radio configuration is the same. Packet will be sent with same radio configuration. 

Also, please be aware that to be able to receive and relay DFU the other nodes should also have the bootloader. Please try to follow the documentation and do a test without any change first. 

[EAn]

Just to make sure I got it clear:

1) Even though changing the PHY layer to CODED for the MESH also affects the OpenMesh PHY (which I presume would be the same). It should work just fine as along as all devices are talking and listening in the same PHY. Correct?

2) All nodes have the same bootloader, which I got from "nrf5SDKforMeshv310src/bin/bootloader/gccarmemb...

I've been trying the exact example as stated in https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.meshsdk.v3.1.0%2Fmd_doc_libraries_dfu_dfu_quick_start.html. It should be so easy to do.

I've got a few issues with the bootloader verification script: "bootloader_verify.py"

When I verify the DevKit which has the DFU example programmed I get:

ea@ean:/.../nrf5SDKforMeshv310src/tools/dfu$ python bootloader_verify.py 683453712 /dev/ttyACM0
Reading UICR..            OK.
Reading Device page..        OK.
Resetting device..        OK (In application)
Checking serial connection..    OK.

Bootloader verification OK.

Everything goes fine! However, when I do the same for the DevKit programmed with the light_switch binary it get's stuck in the "Reading Device page..        OK." message with the blinking cursor, until I do CTRL+C to stop the apparently halted program...  The output is:

ea@ean:/.../nrf5SDKforMeshv310src/tools/dfu$ python bootloader_verify.py 683669070 /dev/ttyACM2
Reading UICR..            OK.
Reading Device page..        OK.
^CResetting device..        Traceback (most recent call last):
  File "bootloader_verify.py", line 176, in <module>
    reset_device(sys.argv[1], sys.argv[2])
  File "bootloader_verify.py", line 125, in reset_device
    response = read_serial_event(s)
  File "bootloader_verify.py", line 40, in read_serial_event
    length = s.read()
  File "/home/ea_bn/anaconda3/lib/python3.6/site-packages/serial/serialposix.py", line 483, in read
    ready, _, _ = select.select([self.fd, self.pipe_abort_read_r], [], [], timeout.time_left())
KeyboardInterrupt

Mind that both were programmed with a bash script I wrote that follows all the steps of the tutorial for the programming. An excerpt:

(...)

#program the softdevice
echo -e "\n### Programming the Softdevice <$SOFTDEVICE> ###"
eval $"nrfjprog --program $MESH_SDK/bin/softdevice/$SOFTDEVICE --chiperase -s $SERIAL_NUM"

#program the bootloader
echo -e "\n### Programming the Bootloader <$BOOTLOADER> ###"
eval $"nrfjprog --program $MESH_SDK/bin/bootloader/gccarmemb/$BOOTLOADER -s $SERIAL_NUM"

#program the application
echo -e "\n### Programming the Application <$APPLICATION> ###"
eval $"nrfjprog --program $APPLICATION -s $SERIAL_NUM"

#program the flash_page
echo -e "\n### Programming the Device Page <$DEVICE_PAGE> ###"
eval $"nrfjprog --program $MESH_SDK/tools/dfu/bin/$DEVICE_PAGE -s $SERIAL_NUM"

(...)

The only thing varying between the programming of the dfu example vs light-switch example is the application .hex file....

Am I missing something?

[EAn]

Hi there!

it's been almost a week. I don't know how this issue got closed, but it is not closed! (edit: I think I accidently pressed the "verify answer" and that closed the issue. I was able to undo it. Sorry I'm still a newbie on this forum )

Hung Bui and whoever might assist at Nordic or in the Dev community. Any clue how to proceed with this? It's a very important feature in the system we are deploying very soon and this is putting behind our development ...

Thank you for your assistance.

//EA

[UdjinPr]

Hello!

I faced with the same issue. I can't do DFU OTA after provisioning of a node. What was the problem in your case?

Best,

Evgeny

[EAn]

Hello there Evgeny,

Well, my situation was the one explained. My main problem is that the DFU OTA offered by Nordic simply doesn't work for Mesh if you have a longer firmware image. It will eventually fail. I never had success when I tried do a DFU OTA with something the size of the light-switch server or bigger... I had success when "updating" to something small like a blinky example.... And if I recall correctly you don't need to do any provisioning because OpenMesh works in parallel to BLE Mesh

Am I wrong Hung Bui?

Eventually I left this DFU and wrote my own proprietary protocol that interfaces with the bootloader... There are still some unresolved issued related to how the Bootloader expects the new transaction to erase flash and prepare for DFU, but that's a story for another issue which I will probably have to post if I fint no solution...

Regards!

//EA