cancel
Showing results for 
Search instead for 
Did you mean: 

What are the best way to split graphical assets and program bin files?

oe2
Associate III

I don't know fi this is the correct place for this question... It's realy more about objcopy than touch_gfx. But on the other hand if somebody else have the problem it suites fine here...

I have my assets (ExtFlashSection, FontFlashSection and TextFlashSection) in an external QSPI flash.

Now I have a demand for OTA, and since th bin file coveres a large area of "nothing" between the internal and external flash the logical thing is to split it in two half using objcopy. This works fine if I remove ExtFlashSection and relocalte FontFlashSection and TextFlashSection to the internal memory of my stm32f7 mcu.

But I would like to put all my sections that are loaded to "qspi_flash_memory" to a separate bin file. (I have some other big segments going to my qspiflash aswell)

I have not been able to figure out how (if even possible) to get multipple sections (perhaps even a "MEMORY" defined in my linker file) in the correct order with objcopy.

I guess it would be possible to remove all "unwanted sections" from each new bin file... using --remove-section over and over agian... but there are a lot of sections...

If I use --only-section i'm not sure about the exported order of the segments. Are they in "memory adress order" or "parameter order" or some random order? 

How can I be certain that the created bin file be in the "correct order"??

Anyone that knows objcopy, or have another good idea?

1 ACCEPTED SOLUTION

Accepted Solutions
VKost.1
Associate II

In your linker script you define memory area for external flash:

MEMORY
{
    INT_FLASH	(rx)	: ORIGIN = 0x08000000,	LENGTH = 128K
    EXT_FLASH 	(rx)	: ORIGIN = 0x90000000,	LENGTH = 1M
}

Then you put all your sections you want to reside on the external flash, as the order of inclusion of the sections determines the order they'll be combined by the linker:

SECTIONS
{
  EFlash_Section :
  {
	*(TextFlashSection TextFlashSection.*)
	*(FontFlashSection FontFlashSection.*)
	*(ExtFlashSection ExtFlashSection.*)
 
	*(.gnu.linkonce.r.*)
	. = ALIGN(0x4);
  } >EXT_FLASH
}

Then as a post-build step, you use objcopy to generate a binary, containing just this external flash section (the second objcopy creates a BIN from the stripped ELF file):

arm-none-eabi-objcopy -j EFlash_Section ${BuildArtifactFileBaseName}.elf ${BuildArtifactFileBaseName}-EFlash.elf && arm-none-eabi-objcopy -O binary ${BuildArtifactFileBaseName}-EFlash.elf ${BuildArtifactFileBaseName}-EFlash.bin

View solution in original post

5 REPLIES 5
VKost.1
Associate II

In your linker script you define memory area for external flash:

MEMORY
{
    INT_FLASH	(rx)	: ORIGIN = 0x08000000,	LENGTH = 128K
    EXT_FLASH 	(rx)	: ORIGIN = 0x90000000,	LENGTH = 1M
}

Then you put all your sections you want to reside on the external flash, as the order of inclusion of the sections determines the order they'll be combined by the linker:

SECTIONS
{
  EFlash_Section :
  {
	*(TextFlashSection TextFlashSection.*)
	*(FontFlashSection FontFlashSection.*)
	*(ExtFlashSection ExtFlashSection.*)
 
	*(.gnu.linkonce.r.*)
	. = ALIGN(0x4);
  } >EXT_FLASH
}

Then as a post-build step, you use objcopy to generate a binary, containing just this external flash section (the second objcopy creates a BIN from the stripped ELF file):

arm-none-eabi-objcopy -j EFlash_Section ${BuildArtifactFileBaseName}.elf ${BuildArtifactFileBaseName}-EFlash.elf && arm-none-eabi-objcopy -O binary ${BuildArtifactFileBaseName}-EFlash.elf ${BuildArtifactFileBaseName}-EFlash.bin

oe2
Associate III

Thanks VKost! 

I didn't know that I could "nest" my sections in the linker file! 

BR Ola

Does anyone know how to do this in IAR .icf linker files and external tools, so a separate .bin file is generated for external flash only?

Your solution works, but now my binary (main program binary, not the EFlash_Section binary) is over 2GB big.. is there a way to fix this issue ?

If you have IAR, use this command to produce bins: elftool your_app.out your.bin --bin-multi

This will extract continuous chunks of data to a number of bin files with the base address in hex appended to names. Then take the parts that you need.