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.
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
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