I've suddenly found that the .*bin file generated by IDE (S32DS) is too large,and bigger than the chip's capability after I put some code to SRAM_U (S32K142) by using *.ld file (Custom Section Block). See below:
Any solutions would be very appreciated.
thanks.
Solved! Go to Solution.
Thanks for the additional details.
If the data in your custom RAM section (".FlashOperation") are not initialized you basically need to tell linker not to load the section.
This can be done by adding NOLOAD argument:
.FlashOperation (NOLOAD):
{
KEEP(*(.flashoperation))
} > m_flashoperation
Hope it helps.
Stanislav
Hi,
I assume you are building "Debug_FLASH" build configuration which is basically creating ROM image of your application. There should not be any content in your binary file in RAM - since after power on reset such a RAM section is not initialized.
If a binary file (ROM image) contains a block of data placed into RAM - this creates huge gap since RAM starts around at 0x2000_0000 whereas FLASH memory block starts at 0x0000_0000.
A Raw Binary file is continuous memory block and the gaps are filled with a dummy values.
This is possibly the reason why your raw binary file is so big.
I'd recommend you to check the s-record file and search for RAM addresses. If your s-record contains a RAM address try to match this address with a linker section that is responsible for this.
Seems in your case the section responsible for the gap is ".CustomSectionBlock".
The solution is to change the load address of this block and place it into FLASH.
.CustomSectionBlock : AT(ROM Address)
where "ROM Address" is address in rom where image of this ram section should be placed.
Typically it is the first free address in FLASH after all ROM sections (.text, rodata,...)
Could you possibly post your .ld file and .map file if it does not help.
Regards,
Stan
Hi Stanislav,
Yeah you assumption is right, but the answer might not work out for me. I wanna define an array which has its name pointer pointed to a certain RAM address at which located from 0x20000440 to 0x200006c0. The executable data to be stored in the RAM area (0x20000440~0x200006c0) are designed to be downloaded from Upper Computer via LIN communication. Which means that after power on reset, data will be placed to "0x20000440~0x200006c0" properly so that I can use "CopyToRAM[index]" to access those address area directly. see below code snippet:
and I've open the RAM area in SRAM_U:
then place the data to the absolute address:
That's really helps me when accessing a certain SRAM_U memory. but the *.bin file expanded as long as I put the "CopyToRam[]" array to SRAM_U through this way.
is that possible to use this way to access a certain absolute address at RAM meanwhile the *.bin that generated is not affected?
thank you!
Thanks for the additional details.
If the data in your custom RAM section (".FlashOperation") are not initialized you basically need to tell linker not to load the section.
This can be done by adding NOLOAD argument:
.FlashOperation (NOLOAD):
{
KEEP(*(.flashoperation))
} > m_flashoperation
Hope it helps.
Stanislav
can i used in the s32DS for PA program? my mpc5744P also creates a bin file is too big.
Hi Stanislav,
I have solved the too big .bin file problem by your suggest.But I find the .bin file be filled with 0x00 for 0x0000 to 0xb000 at same time.(PS. I generate app.bin file for bootloader appcation,the start address of app code is 0x4000)
How can I need to set for this problem? I need the app.bin code start at 0x4000.
BTY, I find the m_interrupts in 0x3c00,the m_data in 0x4410.This circumstances different with my config.
Hi Stanislav,
Thanks for support ! I have solved this problem.Tks!
Thanks man, it worked! Thanks again for your help!