This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

armhex utility generates huge bin file

Other Parts Discussed in Thread: NOWECC

Hi forum,

I'm developing for RM48 with CCS5.4.

I've updated from compiler v5.0.6 to v5.1.2 in order to use the new linker option vfill (virtual fill) and the new possibility to let the linker generate ECC data. That works so far.

But I've observed that the armhex utility (used as post build step) takes much more time (about 3 minutes) and the generated bin file has a size of 3.9GB (!).

Is it possible that the the armhex utility has problems with an .out file that is generated with the vfill linker option?

Best regards
Ädu

  • Could you please post the options and command file you are using with the armhex utility? The vfill linker option should not cause this issue.

  • Hi Codya
    here my post build step command line:

    "../../../../makeBin/tiobj2bin.bat" "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.bin" "${CG_TOOL_ROOT}/bin/armofd.exe" "${CG_TOOL_ROOT}/bin/armhex.exe" "../../../../makeBin/mkhex4bin.exe"

    and here the linker command file:

    --retain="*(.intvecs)"
    --args=0x100
    -heap=0x20000

    #define APP_START_ADDRESS 0x00010000

    MEMORY
    {
        VECTORS     (X)  : origin=APP_START_ADDRESS length=0x00000020
        FLASH       (RX) : origin=APP_START_ADDRESS+0x00000020 length=0x002FFFE0-APP_START_ADDRESS vfill=0xFFFFFFFF
        // RAM: Partitioned into STACKS, RAM and RAM_NOINIT
        STACKS      (RW) : origin=0x08000000 length=0x00003800
        HEAP        (RW) : origin=0x08003800 length=0x00020000
        RAM         (RW) : origin=0x08023800 length=0x0001C700
        RAM_NOINIT  (RW) : origin=0x0803FF00 length=0x00000100
        // HETPROG: Part of peripherals-frame
        HETPROG     (RW) : origin=0xFF460000 length=0x00000A00

        ECC_VEC  (R) : origin=0xf0402000 length=0x00000004 ECC={ input_range=VECTORS }
        ECC_FLA0 (R) : origin=0xf0402004 length=0x5DFFC ECC={ input_range=FLASH }
    }

    ECC {
        algo_name : address_mask = 0x003ffff8
        hamming_mask             = R4
        parity_mask              = 0x0c
        mirroring                = F021
    }

    SECTIONS
    {
        .intvecs : {} palign(32), fill=0xFFFFFFFF > VECTORS
        .text    : {} palign(32), fill=0xFFFFFFFF > FLASH
        .const   : {} palign(32), fill=0xFFFFFFFF > FLASH
        .cinit   : {} palign(32), fill=0xFFFFFFFF > FLASH
        .pinit   : {} palign(32), fill=0xFFFFFFFF > FLASH
        .bss     : {} > RAM
        .data    : {} > RAM
        .sysmem  : {} > HEAP
        .stack   : {} > STACKS
        .no_init_ram_sect : {} type=NOINIT > RAM_NOINIT
        .HETCODE : {e_HETPROGRAM0_UN = .;}  > HETPROG  /* HET PROGRAM  */
    }

    When I remove the ECC stuff from the command line (ECC_VEC and ECC_FLA0) it runs as expected (bin file size is 514kB).

    Regards
    Ädu

    Edit: Corrected APP_START_ADDRESS

  • Ädu,

    I think there is a problem in your ECC generation.

    If your vectors starts at 0x1000 than the ECC range should start at 0xf0400200 not at 0xF0402000.

    Relation from data address and size to ECC offset and size is always 8:1.

    So a data start address of 0x1000 will result in a ECC start offset of 0x200 (0x1000 / 8), a data length of 0x20 will result in a ECC length of 0x4 (0x20 / 8).

    So the Linker should accept the following code in your case (not tested!):

    ECC_VEC  (R) : origin=(0xf0400000 + (APP_START_ADDRESS >> 3)) length=(0x00000020 >> 3) ECC={ input_range=VECTORS }

    ECC_FLA0 (R) : origin=(0xf0400000 + ((APP_START_ADDRESS + 0x00000020) >> 3 )) length=((0x002FFFE0 - APP_START_ADDRESS) >> 3) ECC={ input_range=FLASH }

    Best Regards,
    Christian

  • Christian
    Thanks for the quick answer. Unfortunaltely I had mistake in my post. In fact the APP_START_ADDRESS is defined as 0x10000 not 0x1000. I've lost the zero when i've copied it into my post. Sorry for the confusion.


    With APP_START_ADDRESS 0x10000, the  ECC range of 0xf0402000 is correct, isn't it?

    Best regards
    Ädu

  • Yes, in this case offset 0x2000 is correct!

  • Hi Codya, were you able to reproduce the problem with my linker command file and command line options provided some posts above?

    Thanks
    Ädu

  • Ädu,

    Cody was able to reproduce this offline and figured out that this behavior is no bug, it is expected.
    The problem with BIN files is, that they can't represent holes in the image and thus the armhex tool will fill all holes between the memory sections. In your case, there is a huge hole between 0x300000 and 0xF0400000 and thus the BIN file is going to be really huge (~3.9GB).

    If you need a image of your executable you should consider to you a HEX file format instead.

    BR,
    Christian

  • Christian,
    thanks for your answer.

    Just for my understanding:
    When I'm adding ECC data using nowECC and then generate the bin file with armhex, it works. But also in that case I have the hole between flash start address 0x000000 and the ecc data data at 0xf0400000.
    In my undertstanding the way I generate the ECC data (either by the linker or by nowECC) should have no effect to my .out file used as input file for the armhex utility.

    Thanks for clarification
    Ädu