nrfutil settings generate very slow

RE: nrfutil settings generate very slow

tke — Wed, 19 Sep 2018 05:34:18 GMT

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

}

RE: nrfutil settings generate very slow

Rune Holmgren — Mon, 12 Mar 2018 16:06:23 GMT

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

RE: nrfutil settings generate very slow

tke — Sun, 11 Mar 2018 10:35:59 GMT

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

RE: nrfutil settings generate very slow

Rune Holmgren — Tue, 06 Mar 2018 12:47:18 GMT

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