Insufficient resources on DFU OTA

RE: Insufficient resources on DFU OTA

tkstreet — Thu, 12 Jul 2018 00:43:38 GMT

Hi Terje,

I am having this same issue. I compiled my code with GCC and -Og and -g3 set, so the code is quite big (709kB). However, it flashes with the bootloader and softdevice without any problems using nRFgo Studio and nrfjprog. It is only when I try to do a DFU that it fails with the "INSUFFICIENT RESOURCES" error. Why would this happen?

EDIT: Nevermind. I found this thread that pointed out not to merge the settings hex with the application hex when creating a DFU package and only to do it when flashing the original application file. I generated a new package without merging with the settings hex and the error went away.

RE: Insufficient resources on DFU OTA

tesc — Thu, 03 May 2018 09:23:34 GMT

What if you first try an application update. If it fails, in this particular way, you do a bootloader update before retrying?

RE: Insufficient resources on DFU OTA

chrizz — Wed, 02 May 2018 13:54:13 GMT

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 😒

RE: Insufficient resources on DFU OTA

tesc — Wed, 02 May 2018 08:43:03 GMT

Hi,

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.

Regards,
Terje

RE: Insufficient resources on DFU OTA

chrizz — Wed, 02 May 2018 08:19:06 GMT

Hi tesc,

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

in nrf_dfu_types.h

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)?

RE: Insufficient resources on DFU OTA

cjishnu — Tue, 01 May 2018 07:23:53 GMT

Thanks. I had the exact same issue and I had forgotten to include the 3 pages of application data in my code size calculation. After decreasing the code size, DFU works.

RE: Insufficient resources on DFU OTA

tesc — Mon, 30 Apr 2018 13:06:31 GMT

Hi,

140 kB (0x23000 bytes) is the size of some versions of SoftDevice s132, but the size varies. For instance s132 version 6.0.0 (from SDK 15) is 152 kB (0x26000 bytes). Earlier versions are smaller in size.

Regards,
Terje

RE: Insufficient resources on DFU OTA

tesc — Mon, 30 Apr 2018 13:02:13 GMT

Hi,

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:

Application data. This is non-volatile storage used by an application. As a huge oversimplification it can be compared to a desktop application storing files to disk. Application data is used for instance by peer manager (through FDS), and it is located next to the bootloader (at lower flash address than the bootloader. Usually two or three flash pages, which on the nRF52832 means address 0x7000 or 0x6b00. See the Infocenter section on Memory layout.
Forcing dual bank update. Dual bank update means only free space in flash is used for downloading the new application. This means if anything goes wrong with the DFU you can still boot into the old application. (In contrast, with single bank you will end up in the DFU bootloader after an unsuccessful application update, and would have to do a successful DFU in order to get a working application after that.) By default the update is dual bank if enough space is available, but single bank is used as a fallback. Disabling single bank as a fallback requires changing a define in the bootloader source code and so this may be an issue only if you have done so. See also Dual-bank and single-bank updates.

Regards,
Terje

RE: Insufficient resources on DFU OTA

hari911 — Sat, 28 Apr 2018 04:26:02 GMT

Hi Chrizz,

So, from my understanding, in case of nRF52832, S132 is expected to consume 0x00 - 0x23000 and the bootloader starts from 0x73000. So the application program space available is 0x50000 -> 320kB. Am just a beginner with nRF boards an also on to the nRF OTA bootloader.