I am using NSDK 15.3, MeshSDK 3.2.0, SoftDevice 6.1.1 and nRF52840 DKs.
I successfully integrated the DFU capabilities in my firmware that uses BT Mesh. I am downloading the firmware from the internet using an ethernet chip, storing the firmware in RAM and calling nrf_mesh_dfu_rx from a timer interrupt to have the interrupt level in order.
I had a board successfully upgrade from the DFU example firmware to the blinky firmware, but the blinky firmware is 1700 bytes long.
When I try to upgrade with a larger firmware, the probability of packet loss is naturally greater, and even more since we are using the radio for both Mesh and DFU.
The problem arises when these packets are lost and the target board triggers a data recovery request.
I am seeing these packets arriving in the sender board (packets preceeded with FFFB) and I am sending the requested packets back (preceeded with FFFA). The funny thing is... these packets are also arriving in the target board, but the DFU transfer ends up failing, triggering DFU EVENT END after some time (I suspect after a set number of packets have been lost or some time after the first packet loss).
Can you guys confirm if the bootloader is correctly handling the DFU DATA RSP packets? Up until now I have only messed around with the application side of things and I would prefer not to invest too much time on researching the bootloader on my own right now.