I am using NSDK 15.3, MeshSDK 3.2.0, SoftDevice 6.1.1 and nRF52840 DKs.
Hello, I have followed the documentation for the DFU over mesh here and successfully upgraded a board with the blinky FW binary.
I then generated a firmware package of my custom application and tried to do a DFU over mesh. It didn't work. I then modified the original dfu example to log some info on the Segger terminal with RTT and found out that the recovery of lost segments is not working correctly.
It seems that after a couple of correctly processed packets, the DFU stops processing the recovered segments that come with a FFFA handle and so, after receiving some packets after the lost one, the bootloader aborts the DFU and logs "Abort event. Reason: 0x3".
Please test the DFU over mesh with something bigger than 1KB, since it is easy to get the blinky binary into the board since the probability of having lost packets is too small compared to a mesh enabled FW that is at least 100KB big.
Also, it seems that the flash manager takes some time to allocate memory (maybe for banked transfer?) and the larger the firmware to be transfered, size information transfered in the START DFU packet, the longer the flash manager takes to allocate (makes sense). Your nrfutil program doesn't seem to take this into account and the delay between the START DFU packet and the following DATA packets is not enough on a 140KB FW, resulting in the first packet never being processed on the target side. This is what led me to discover the problem faster, since the first data packet was always being received if I used the blinky FW for the DFU transfer, most of the times if I used the DFU example and never when using my custom 140KB application for the transfer.
Yes, I made a similar post last week about this problem, but in the mean time I thought the problem was on my side. After testing with a clean slate SDK and confirming the problem was still happening, I decided to make a new post since the previous one was already marked resolved by me and closed.
