Mesh DFU not terminating after update is complete

RE: Mesh DFU not terminating after update is complete

Hung Bui — Tue, 07 Dec 2021 13:24:15 GMT

Hi Jeffe,
Thanks for the info. Please keep us updated if you observe the issue again. I suspect that it might a corner case that hard to reproduce.

The link to the RTT case was unfortunately a private case. So that's why you couldn't read it. But it's about an issue of RTT memory conflict between application and bootloader.

RE: Mesh DFU not terminating after update is complete

Jeffe — Mon, 06 Dec 2021 22:29:57 GMT

Hi Hung,

Apologies for the late reply.

So far the issue is fairly uncommon and difficult to reproduce. I had no luck reproducing it so far. Let me know if the Mesh Developers decide to introduce a timeout before starting new relaying as I will be interested in such a patch. At the moment, however, I have become busy with other things so I will come back to this issue in the future and investigate at a much later date.

The link for the bootloader RTT logging problem is broken (I get "Access Denied")? But anyways it is a bummer that RTT logging does not work for the bootloader. On the other hand, I figured out how to build the bootloader with cmake thanks to your links.

Also thank you for the segger embedded studio project file, I will keep a bookmark on that when I come back to this. Thank you for your support!

RE: Mesh DFU not terminating after update is complete

Hung Bui — Thu, 02 Dec 2021 12:19:10 GMT

Hi Jeffe,
My name is Hung. I'm taking over the case from Håkon.

We are suspecting your issue is similar to this case: https://devzone.nordicsemi.com/f/nordic-q-a/56151/mesh-dfu-relay-problem

But it should be solved from SDK v4.2 and it's a corner case where there is no application on one of the board (just Softdevice and Bootloader) in your case it's a bit different. For some reason the FWID beaconing has been relayed forever in the network. This should not happen normally. If you observed the issue again please let us know. We are thinking of having to introduce a timeout before starting new relaying at: https://github.com/NordicSemiconductor/nRF5-SDK-for-Mesh/blob/master/examples/dfu/src/main.c#L149

Regarding your question, the problem with RTT logging for the bootloader is that we have an issue that the RTT logging for application will take over and that's why you don't see any log from the bootloader. We haven't got a clear solution for that. You can have a look at the answer here.

But if you want to be easier to debug the bootloader you can think of using the Segger Embedded Studio project for bootloader. We provided one here for SDK v4.x: https://devzone.nordicsemi.com/f/nordic-q-a/51534/stepping-through-nrf-mesh-bootloader-code-in-segger-embedded-studio

RE: Mesh DFU not terminating after update is complete

Jeffe — Wed, 01 Dec 2021 21:46:36 GMT

Ok I have done a couple of DFU on a test mesh network (same network as the one in the initial post), and so far I have not been able to replicate it (i did about 7-8 DFU updates with the application). It seems like this issue is not common although the uncertainty is not ideal.

I would like to recompile the bootloader so that it can print to RTT, however, I am not sure how to compile it. I have followed the instructions in the infocenter and I am able to build the examples with cmake without issues. However, when attempting to build the bootloader, nothing happens at all (i run the makefile generated by cmake in the mesh bootloader directory, and it did nothing). How do you compile the mesh bootloader?

RE: Mesh DFU not terminating after update is complete

Jeffe — Mon, 29 Nov 2021 16:52:48 GMT

Alright, thank you for looking into this!

In the meantime I will conduct more DFU tests to see if I can figure out if there is a way to reliably replicate this issue, since at the moment it only happens sometimes

RE: Mesh DFU not terminating after update is complete

Elfving — Mon, 29 Nov 2021 15:28:20 GMT

Hey Jeffe!

I'm looking into it, but I will have to get back to you.

Though the DFU is being relayed to make sure that all nodes gets it, and they wouldn't have much of a way of knowing that every node already does. Normally you could limit the TTL if you would like the relaying to stop faster, though the proprietary DFU in our Mesh SDK uses the IETF Trickle algorithm instead, so it might not be that easy.

Best regards,

Elfving