On our device, we're seeing a problem when trying to run a Mesh DFU to update our firmware.
We first generated a DFU package with application version Y. Then we tried sending it along to our hardware that has application version X, compiled with the "Release" configuration in Segger v4.16. However, it rejected the DFU package due to sizing. The mesh bootloader returned abort code 0x0d (DFU_END_ERROR_BANK_AND_DESTINATION_OVERLAP /**< When copying the finished bank to its intended destination, it will have to overwrite itself. */).
Oddly enough, when we program the hardware with application version X but compiled with the "Debug" or "ReleaseWithDebugInformation" configuration, it happily accepts the DFU package.
When we looked into the mesh bootloader code, we found this is where it's throwing the abort code, in mesh/bootloader/src/dfu_mesh.c:
if (m_transaction.p_start_addr != m_transaction.p_bank_addr &&
section_overlap((uint32_t) m_transaction.p_start_addr, m_transaction.length,
(uint32_t) m_transaction.p_bank_addr, m_transaction.length))
{
send_end_evt(DFU_END_ERROR_BANK_AND_DESTINATION_OVERLAP);
start_find_fwid();
return;
}
It seems like it's refusing to accept the package because the storage section will overlap with the resulting application section after it is transferred. Is that correct? If so, it seems like it won't ever accept an update that uses more pages in flash since the p_bank_addr is always set to p_start_addr + old_app_length. If the new length is larger than the old_app_length, then p_bank_addr < p_start_addr + m_transaction.length, which is not allowed.
Is my understanding correct? If so, how can we send over an application update that's larger than the previous application?
For reference, we are using nRF5 SDK for Mesh v3.1.0 (nrf5SDKforMeshv310src)
