cancel
Showing results for 
Search instead for 
Did you mean: 

TGX: Very large external flash file

CPaye.1
Associate III

Hello,

I am using Touchgfx v4.16.1 with an STM32F469 Discovery Board.

I used Touchgfx Designer to generate two different applications for the Discovery Board. In both cases when I build the applications using the makefile, the external Flash file that is created is over 2 GB. I looked at the mapfile for each application and for both applications the memory used in the external flash space is much, much smaller. One of the external applications does not have any images in it so the external flash is only being used for fonts (approximately 400 bytes of memory). I removed the "-g" option from the makefile to try to eleminate the creation of debug symbols but that did not help.

I can use Designer to load these applications onto the Discovery board and they run fine. I know the external flash file is much, much larger than the external flash on the Discovery board so it appears that only part of it is being loaded.

I have used TGX previously and did not have this issue. The size of the external flash file generated in my previous application correlated with the number of images and fonts in the application. However this is the first time I am using the autogenerated makefile from Designer. Unfortunately I do not have access to the makefile from my older application so I cannot compare the two.

Why is there such a mismatch between what is actually being put in external flash and the size of the file? I feel like I am overlooking something silly but I do not know what. Any insight would be appreciated.

Thanks.

1 ACCEPTED SOLUTION

Accepted Solutions

.BIN or .HEX ?

Binary files can't have any gaps, whereas hex files can be sparse.

Something describing 0x08000000 thru 0x91FFFFFF is apt to be quite massive... 2GB ish

Break the the binary into sections of memory which actually exist within the processors address space.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

View solution in original post

2 REPLIES 2

.BIN or .HEX ?

Binary files can't have any gaps, whereas hex files can be sparse.

Something describing 0x08000000 thru 0x91FFFFFF is apt to be quite massive... 2GB ish

Break the the binary into sections of memory which actually exist within the processors address space.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
CPaye.1
Associate III

@Community member​ The external flash file is a .BIN file.

Good catch that 0x08000000 - 0x91FFFFFF is around the size of the file I am getting.

I looked through the makefile and there is this section:

@echo "  intflash.elf - Internal flash, elf debug"
	@$(objcopy) --remove-section=ExtFlashSection $@ $(@D)/intflash.elf 2>/dev/null
	@echo "  intflash.hex - Internal flash, hex"
	@$(objcopy) -O ihex --remove-section=ExtFlashSection $@ $(@D)/intflash.hex
	@echo "  extflash.bin - External flash, binary"
	@$(objcopy) -O binary --only-section=*FlashSection $@ $(@D)/extflash.bin

The last line in the snippet is trying to copy over only the sections that are mapped to external flash in the linker (ExtFlashSection, FontFlashSection, TextFlashSection). I changed the last line to explicitly only use the sections that belong in external flash:

@echo "  extflash.bin - External flash, binary"
	@$(objcopy) -O binary --only-section=ExtFlashSection --only-section=FontFlashSection --only-section=TextFlashSection $@ $(@D)/extflash.bin

The size of the external flash file now matches what I am seeing in the map file.

I am not sure why the wildcard in the objcopy command is not working the way it should. (Or maybe it is? I'm not a makefile expert.)

Thanks for the insight.