on trying to update firmware on nrf52832 over the air I'm getting the error message INSUFFICIENT_RESOURCES.
Actually I don't understand the error message because if I generate the bootloader settings page for the firmware image and flash both hex files separately (the firmware and the bl settings page) everything works as expected. For our customers I wan't this firmware image to be updated using DFU OTA so I generate a zip file with nrfutil:
nrfutil pkg generate --hw-version 52 --application-version 1 --application myfirmware.hex --sd-req 0x8c --key-file ../keys/private.pem update_file.zip
I need to say that since our last update we added a ton of features and a huge binary blob of about 60 kB so that the resulting image has a size of 348 kB. Regarding the nrf52 memory layout the firmware image starts at 0x1f000. The bootloader starts at address 0x78000. So from my understanding the firmware exactly fits into the space between 0x1f000 and 0x78000. Correct me if I'm wrong. Do I miss something? Are there any restrictions regarding file size and DFU OTA update?
You are correct that the flash requirement of SoftDevice s132 version 3.0.0 (which is the one you use for generating the DFU zip with --sd-req 0x8c) is 124 kB (0x1F000 bytes). That means the application starts at 0x1F000.
You are also correct that the bootloader (usually) starts at 0x78000.
There are mainly two things that might reduce what size is possible for an application over DFU:
2. I think this is not the case here since the application size forces a single bank update.
1. What if my application neither uses the application data region nor the peer manager? I mean 12kB (3 pages) is a lot of space one could use for "useful" things like e.g. code.
On a quick look I found
#define DFU_APP_DATA_RESERVED CODE_PAGE_SIZE*3
Is this the line I would need to patch for the bootloader to flash from APP_IMAGE_START_ADDR to UICR_BOOTLOADER_START_ADDR? Can I somehow circumvent the bootloader from preserving this memory (without patching the bootloader code)?
Yes, that is the line to change. If you do not use application data at all (and do not use any libraries such as peer manager that does) then setting it to 0 is safe.
It is a compile time bootloader setting, and it cannot be overridden. (Fortunately, some would say, as changing it during DFU would allow for erasing application data.) So no, it cannot be circumvented and you need a bootloader that is built with the correct setting. Of course, you can do a bootloader upgrade first, to a bootloader with the new setting, then do the application update.
Yes, of course we can. On the other hand we want our customers to do as less updates as necessary. But now for a firmware update we need our central device to be able to retrieve the bootloader version in order to update the bootloader followed by the large(r) firmware image once the bootloader is up to date
What if you first try an application update. If it fails, in this particular way, you do a bootloader update before retrying?