How to fill all memory blocks with a FILL value?

[emagii]

Hi, 
I would like to run an application on the generated ELF file which first fills all holes between
the segments within a certain memory range, and then computes a custom CRC value.

When the modified ELF file is flashed to the board, I run into a "Programming Error".
When comparing the unmodified ELF file with the modified ELF file;
the most obvious change is that the "fill" is generated as new sections in the ELF file.
The sections will not appear in consecutive order and has an alignment of 4 bytes.
(filler segments have zero alignment)

If I run the application, just to generate the CRC, programming succeeds.
The problem I see is that without the fill, the CRC computation will not match that of the target.

In order to continue, I would like to fill all "holes" in the desired address range using the linker.

I can see that I get the fill value in the S-Record file, but it seems incomplete.

For this to work, I need to have the fill value in the ELF file.
It appears to only fill my first section.

So how do I fill everything up to the end of a MEMORY block?
===================

$ readelf -l Stage2.elf

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

Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x0003e0 0x00008000 0x00000000 0x00100 0x00100 R E 0x4
LOAD 0x0004e0 0x00008100 0x00000000 0x00020 0x00020 R E 0x4
LOAD 0x000500 0x00008120 0x00000000 0x00ee0 0x00ee0 R E 0x4
LOAD 0x001480 0x00009000 0x00000000 0x000f4 0x000f4 R E 0x100
LOAD 0x001580 0x00009100 0x00000000 0x000d4 0x000d4 R E 0x100
LOAD 0x002480 0x0000a000 0x00000000 0x03604 0x03604 R E 0x10
LOAD 0x005a88 0x0000d608 0x00000000 0x00380 0x00380 R 0x8
LOAD 0x005e08 0x0000d988 0x00000000 0x0016c 0x0016c R E 0x4
LOAD 0x005f80 0x0000db00 0x00000000 0x00500 0x00500 RWE 0x10
LOAD 0x007080 0x40008000 0x00000000 0x00000 0x00ff0 RW 0x1000
LOAD 0x007080 0x0000e000 0x00000000 0x0008c 0x0008c RW 0x8
NULL 0x007080 0x40008ff0 0x00000000 0x00000 0x0008c RW 0x8
LOAD 0x007110 0x0000e090 0x00000000 0x00004 0x00004 RW 0x8
NULL 0x007110 0x40009080 0x00000000 0x00000 0x00004 RW 0x8
LOAD 0x007118 0x40009088 0x00000000 0x00000 0x00004 RW 0x8
LOAD 0x007118 0x40009090 0x00000000 0x00000 0x02fb0 RW 0x8
Fill sections.
LOAD 0x01d939 0x000090f4 0x00000000 0x0000c 0x0000c R E 0x4
LOAD 0x01d945 0x000091d4 0x00000000 0x00e2c 0x00e2c R E 0x4
LOAD 0x01e771 0x0000d604 0x00000000 0x00004 0x00004 R E 0x4
LOAD 0x01e775 0x0000daf4 0x00000000 0x0e50c 0x0e50c R E 0x4

[emagii]

When I read in the ELF file to calculate a CRC, my tool (ielftool) assumes any unused bytes are zero, not 0xFF, which works for segment loaded to cleared RAM but not for flash.

If I tell ielftool to fill unused values with 0xFF, then it generates och extra segments.

CodeWarrior cannot program the ELF file if the fill segments are present, which I suspect is a bug.

So in order to have a correct CRC in the ELF file I need to fill all the holes in the linker or compile the code twice to generate filler assembler files in the first pass.

I can generate an ELF file in ielftool, and then generate S-Records in ielftool.

Somehow program the S-Record file using CodeWarrior (How?) and then start debugging without download, just loading symbols.

This is again very inconvenient.

So is it impossible to fill in the linker?

[Pavel]

See the following pages about filling in linker:

https://mcuoneclipse.com/2014/06/23/filling-unused-memory-with-the-gnu-linker/

https://stackoverflow.com/questions/64282272/gnu-linker-how-to-fill-unused-memory-space

https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/mpc5xxx/16877/1/Fill_unused_memory_CW_MC...

https://users.informatik.haw-hamburg.de/~krabat/FH-Labor/gnupro/5_GNUPro_Utilities/c_Using_LD/ldLink...

[emagii]

Thanks,
I tried this, but I suspect I found a bug in the linker.

=================
It works to extend a section in the beginning of the image.
GROUP : {
.bam LOAD(ADDR(resetvector)) : {}
} = 0xFFFF > resetvector
.fill_bam LOAD(_e_bam): {
*(.fill_bam)
. = ADDR(resetvector) + SIZEOF(resetvector);
} = 0xFFFF > resetvector

This generates a .fill_bam section which fills the resetvector

=====================

I run into the problem in the internal_flash section.

ROM Image Address and RAM Buffer Address of ROM Image are both set to 0xD00.

I can do:

GROUP : {
.text (TEXT) : {}
.rodata (CONST) : {
*(.rdata)
*(.rodata)
}
.ctors : {}
.dtors : {}
extab : {}
extabindex : {}
ROM_IMG_START = .;
} = 0xFFFF > internal_flash

GROUP : {
.data : {
__data_start__ = .;
*(.data)
}
.sdata : {
__sdata_start__ = .;
*(.sdata)
__sdata_end__ = .;
__data_end__ = .;
}
.sbss : {}
.sdata2 : {}
.sbss2 : {}
.bss : {}
ROM_IMG_END = ROMADDR(.bss);
} > internal_ram

/* calculation of ROM data image size */
ROM_DATASIZE = ROM_IMG_END - ROM_IMG_START ;

ROM_CALC = ADDR(internal_flash) + SIZEOF(internal_flash) - ROM_DATASIZE;

.unused_internal_flash : {
. = ROM_CALC;
}= 0xFFFF > internal_flash

I get an error message:

======================================

C:/Freescale/CW MCU v11.1/MCU/PA_Tools/Command_Line_Tools/mwldeppc|Linker|Warning
>Specified length of memory directive 'internal_flash' was exceeded within
>section '.unused_internal_flash': specified 0x00003200 but length is now

======================================

Note: The error message is not complete.

The map file shows that ROM_CALC is 00003ec8

If I set  "ROM_CALC" to the calculated value (0x3ec8).  it works.

ROM_CALC = 0x3ec8;

.unused_internal_flash : {
. = ROM_CALC;
}= 0xFFFF > internal_flash

==============

If I use the original and deduct an arbitrary value, I srill get the error message,
so there is something broken in the linker.

[emagii]

I just noted the comment:

NOTE: The fill pattern feature does not impact the .elf file. If a default debug session starts the
fill pattern areas are not programmed. In order to program the image including the
fill pattern blocks into Flash the .mot (S-record) file or .bin needs to be programmed
into flash e.g. using the Flash Programmer/Target Task tool.

That is of course a deal breaker.

If the ELF file does not contains the fill sections, you cannot post-process the ELF file to calculate the CRC.

If you add the CRC to the S-Record file, the debug symbols are gone, so you have
to first program the S-Record file (can you do that with CodeWarrior?)
and then load the symbols.

It is really an unwieldy process.

[Pavel]

Perhaps if transform S-record file to binary image and calculate CRC for this binary image is solution for your problem.

[emagii]

I can do this, how do I download and do source level debugging with a binary file?

Converting the ELF file is a better approach.

I can convert the ELF file, but the debugger cannot program the result, which I suspect is a bug that it cannot handle out of order segments.

I can create an ELF file with all segments filled, but due to the bug in the linker, I first have to compile and link to get the size of each segment, then I have to create new filler segments of the right size.

Have all development of the CodeWarrior/PPC stopped?

Otherwise, that is a bug that should be fixed.

[Pavel]

You can debug software and do not use CRC. Add CRC calculation for last burning only.

[Pavel]

Usually data in empty Flash is 0xFF. Use this data as Flash filling.

The S-record write only required addresses. Unused addresses are not writhed.