You are reading a single comment by @Gordon and its replies. Click here to read the full conversation.
  • Just to add to this:

    It looks like the whole firmware is checked with microecc (in nrf_dfu_postvalidate) at the end so right after writing the firmware, it will fail unless we can match the hash (which may be very tricky given its size - although I believe there are some tools out there that can help?).

    However, and @fanoush maybe you have some thoughts here because I think you've looked into this in more detail, but an nRF52832 band almost certainly only has 1 flash bank so it has to overwrite the existing app even before that ECC check. So when you do a firmware update, this should happen?

    • Init packet is sent (with CRC, size, ECC hash, etc)
    • Init packet is correct (it's from an official FW update) so it passes
    • App area is erased, and the supplied firmware is written without any real checks
    • Right at the end, it validates the firmware and will fail the ECC check - but all the firmware from the zip file is now actually on the device in the right place

    So really it depends whether nrf_dfu_settings_write is ever called to invalidate the bank - because if not then it's possible that it could reboot, check the CRC of the data in flash (which would have been crafted to match what was on the device) and then passes and executes it?


Avatar for Gordon @Gordon started