DFU Bootloader fails to correctly allocate memory for SoftDevice update

[Tiago Costa]

Hello,

My team and I are experiencing a problem with our custom DFU Bootloader, which is based on the Experimental Bootloader Secure Serial example (SDK 13), running in a custom NRF52832 board. Our main app uses a single bank, and we're also using the S132 v4 SoftDevice, our custom Bootloader and Bootloader settings.

The whole flash process seems to work fine, whether we update the Application, the SoftDevice or the Bootloader itself. However, when our boards are flashed with an application using almost all the flash space allocated to the application, problems occur when attempting to update the Bootloader or the SoftDevice using our custom Bootloader.

When our app uses more than 307200 bytes, leaving only about 3 pages of unused space, the function nrf_dfu_find_cache() fails to safely allocate space for the temporary swap space required by the update process, leading to the write operations overwriting the Bootloader region that is executing the DFU requests. This causes the Bootloader itself to become corrupt and the system hangs (only recovers after a re-flash with the programmer).

We are wondering if this is a known problem with SDK 13 and if there is a solution to the problem. (As a workaround, we're currently limiting our application size in the linker so that it fails to compile if grows beyond the aforementioned size.)

Thank you for your attention to this matter, please let me know if we are required to provide more details regarding this issue, TC

[Tiago Costa]

I know what the bootloader's error is (insufficient resources for app firmware image), so I don't need to step into the code in this scenario. What I don't know is why the app binary file is larger than the limit set in the linker... because, If I specify in the linker than the app must not occupy more than 0x4A000 bytes in memory, why is the binary larger? I believe its due to metadata in the binary that is not actually to be flashed in memory. So I guess the question is, why isn't this metadata ignored when flashing the app? I mean, the firmware image is rejected because of being too large but it should fit as the actual app was compiled for that limit (otherwise, linking would fail). Shouldn't nrfutil generate an init packet with the correct app size to be occupied in memory?

[Hung Bui]

Hi Tiago,

We need to check what is the size of the image according to the compiler. Could you post what you get in the code size, RO, RW data you get after you compile ?

The size of the application by nrfutil, is not based on the hex directly, it's based on the binary converted from the hex. So I don't think it was some metadata cause the size to increase.

[Tiago Costa]

Hi Hung,

I'm filling all the app space with a dummy array. I get a .bin file of size 311940 bytes when I compile with app orig = 0x1F000, len= 0x4C000 and BL settings orig = 0x0007F000, len = 0x1000. The bootloader starts at 0x6E000 (len=0x10000).

Elf file type is EXEC (Executable file) Entry point 0x29cd5 There are 4 program headers, starting at offset 52

• Program Headers:

• Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align

• EXIDX 0x05aff8 0x0006aff8 0x0006aff8 0x00008 0x00008 R 0x4

• LOAD 0x000000 0x00010000 0x00010000 0x5b000 0x5b000 R E 0x10000

• LOAD 0x062c00 0x20002c00 0x0006b000 0x00284 0x04454 RW 0x10000

• LOAD 0x06f000 0x0007f000 0x0007f000 0x00000 0x01000 RW 0x10000

• Segment Sections...

  • 00 .ARM.exidx
  • 01 .text .ARM.exidx
  • 02 .data .fs_data .bss
  • 03 .bootloaderSettings

[Hung Bui]

Hi Tiago,

Which compiler/linker you used ? Could you give the code (text) size after you compile ? If you use gcc, you can use arm-none-eabi-size.exe to check the size.

Or you can use this tool to find the size from .map file.

[Tiago Costa]

Hi Hung, I'm using gcc-arm-none-eabi-5_4-2016q3 in a linux environment. The arm-none-eabi-size tool returns:

text | data | bss | dec | hex 311296 | 644 | 20940 | 332880 | 51450