nrfutil settings generate very slow

[schef]

Hi,

when generating settings on windows using nrfutil on one project takes about 2 minutes and it swallows whole memory during the command.

The command i am using is:

```

nrfutil settings generate \
--family NRF52 \
--application src/pca10040/s132/armgcc/_build/nrf52832_xxaa.hex \
--application-version 1 \
--bootloader-version 1 \
--bl-settings-version 1 \
src/../binary/dfu_settings.hex

```

but on linux i need 450ms.

Thanks.

[Rune Holmgren]

This issue is not something I can recall seeing before.

Are you running the same revision of nrfutil on both the Windows and Linux system with the same python version? If you installed nrfutil from source, try checking out an older commit belonging to an official release and not just the newest master. You may also want to install it directly from pip as it may be simpler. Also ensure that you are running the revision of nrfutil supported by the SDK you are using, most commonly nrfutil version 2.3.0.

Best regards,
Rune Holmgren

[tke]

On iMac Pro High Sierra 3.2GHz Xeon W running similar command I get:

real    0m37.072s
user    0m34.316s
sys    0m2.748s

$ nrfutil version
nrfutil version 3.4.0

$ python --version
Python 2.7.10

The process takes about 8GB memory.

SDK is 13.1

On slow Linux machine:

real    5m10.484s
user    1m32.596s
sys    0m6.552s

$ nrfutil version
nrfutil version 3.4.0

$ python --version
Python 2.7.12

And the machine swaps like hell.

SDK is 13.1

How can check whether the SDK and nrfutil match ?

Cheers, Timo

[Rune Holmgren]

Thank you for the details. When I mentioned the RAM consumption to my colleague working on nrfutil he said it sounds like you have a hex file with data outside of the flash region. Nrfutil expects to get a hex file with the applications flash and it will create a buffer to hold this while it hashes data etc. Unfortunately, there is no check confirming that the hexfile doesn't have any data in the higher regions of flash, so a hexfile with data higher up in the address ranges will cause nrfutil to create very large buffers.

To be sure that there aren't any new RAM consuming bugs introduced in nrfutil 3.4.0 I used a regular application hex file in nrfutil settings generation on a time-shared single core digital ocean "droplet" with 512 MB of RAM. It ran in 0.4 seconds even on such a weak system.

You can either have a look at your own hex file, or you can send it to me and I can have a look at it.

Best regards,
Rune Holmgren

[tke]

Sorry for the late answer, but I just noticed that you've replied.

Yes, the phenomena is due to locating Segger buffers outside the "RAM" area on top of the stack in the end of the ram. In linker script I have memory and sections defined as follows for SD v6.0.0:

MEMORY {
  FLASH (rx)     : ORIGIN = 0x26000,    LENGTH = 0x5a000
  RAM (rwx)      : ORIGIN = 0x20002A98, LENGTH = 0xC510   /* = 0x10000 - 0x2A98 - 0x0048 - 0x1010 */
  RTT_CB (rwx)   : ORIGIN = 0x2000EFA8, LENGTH = 0x0048   /* Control block for single buffers (up & down) */
  RTT_BUFF (rwx) : ORIGIN = 0x2000EFF0, LENGTH = 0x1010   /* Single buffer for both: 4*1024 octets up and 16 octets for down buffer */
}

SECTIONS {

. . .

    .bss :  { ...  } > RAM
    .heap (COPY) : { ... } > RAM
    .stack_dummy (COPY) : { ... } > RAM

    /* Allocate section for Segger RTT Control block */
    .rtt :  {
        . = ALIGN(4);
        __rtt_start__ = .;
        KEEP(*(.rtt))
        __rtt_end__ = .;
    } > RTT_CB

    /* We get quite a few error messages if the origins & lengths of the sections are not right. */
    /* However, better check the alignment here too. */
    ASSERT(__rtt_start__ == ORIGIN(RTT_CB), "RTT CB misplaced or misaligned")

    /* Allocate section for Segger RTT buffers */
    .rtt_buffers : {
        __rtt_buffers_start__ = .;
        KEEP(*(.rtt_buffers))
        __rtt_buffers_end__ = .;
    } > RTT_BUFF

}