Hello there,
Recently I have added and been testing DFU into my existing application. I have conducted a few DFU updates and have noticed a semi-reoccurring issue. I use the nRF SDK for Mesh 5.0.0, and followed the "Configuring and performing DFU" page in the infocenter
I will give some background on my project first: currently the mesh network consists of 2 types of devices (so it is a mixed-device mesh network), and to update the mesh network, I simply just get a nrf52840 DK board with the mesh_DFU example with serial, and use that as the initial point to update all other devices in the network (not sure if this DFU updater can be considered a third device, as it is not provisioned into the bluetooth mesh network, but I did not need to since we use the OpenMesh protocol for DFU updates).
The Mesh DFU update itself goes well - there are no issues with the update. The problem comes after the update is completed. After the updated devices reset, the devices still are stuck in the DFU state - what I mean is that after they have been updated, they are in a loop where they endlessly relay the firmware for basically forever as far as I can tell. The main application and functionality is completely fine and intact though, its just that they just never stop relaying the firmware even though all appropriate devices in the network have completed their DFU update.
To hopefully make myself more clear on what the issue is, I have provided 4 RTT logs of a DFU I have performed where this issue happened when I tested DFU in a 4-device mesh network (including the DFU_example board itself). The "updater.log" file is the DFU-example from the SDK that connects via serial to the computer to receive the DFU package so that it can broadcast it to the rest of the mesh network, and it has an application id of 3. The "client.log" file is 1 device in the mesh network with an application id of 1. The two "server.log" files are the devices the devices that actually underwent the update in this test and have an application id of 2. You can see that they successfully update to a newer version, but then get stuck in an endless cycle of relaying the DFU firmware after their update and subsequent reset. For the interest of readability and size, I have removed the log-messages that are repetitive (since I left the DFU update to be conducted for an entire night).
Note: I forgot to turn on outputting RTT-log saving for the client.log until two hours after I begun the DFU process, hence why its beginning timestamp is different. My apologies, but as far as I can tell, there was not anything abnormal with the client device during the DFU process
Fortunately, since the main application functionality is completely unaffected (as expected though), so it is not the end of the world. The issue is that, if I do not manually reset or power off the device for a couple of times to get rid of this "relaying DFU firmware" state, then a subsequent DFU will fail, which is could either be a minor inconvenience or a huge inconvenience depending on the circumstances.Does anyone have any clues to why this happens?
