2012-05-24 01:11 AM
Please, could you help me? with STM32F4xx.
But I think it's general problem with GNU linker.
I'm working on SW for colour graphical display application.
It works fine.
But I need to store some data to Flash after the program start.
I want allocate for this data all 16K Sector 1 in Flash area.
I have tried different ways but unsuccessfully.
My variable is
const unsigned
short
int
FlashArray[8192].
I have tried this:
const unsigned short
int
FlashArray[8192] __attribute__ ((at((uint32_t)0x08004000)));This doesn't work in GNU.
I have tried also this:
const
unsigned
short
int
FlashArray[8192]
__attribute__
((section(
''.flash_data_array''
)));
+
change in stm32_flash.ld:
/* Specify the memory areas */
MEMORY
{
FLASH0 (rx) : ORIGIN = 0x08000000, LENGTH = 16K
FLASH1 (rx) : ORIGIN = 0x08004000, LENGTH = 16K
FLASH2 (rx) : ORIGIN = 0x08008000, LENGTH = 992K
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
MEMORY_B1 (rx) : ORIGIN = 0x60000000, LENGTH = 0K
}
/* Define output sections */
SECTIONS
{
/* The startup code goes first into FLASH */
.isr_vector :
{
. = ALIGN(4);
KEEP(*(.isr_vector)) /* Startup code */
. = ALIGN(4);
} >FLASH0
/* My new eeprom area in FLASH */
.flash_data_array :
{
*(.rodata) /* .rodata sections (constants, strings, etc.) */
*(.rodata*) /* .rodata* sections (constants, strings, etc.) */
. = ALIGN(4);
KEEP (*(.init))
KEEP (*(.fini))
. = ALIGN(4);
} >FLASH1
?
/* The program code and other data goes into FLASH */
.text :
{
. = ALIGN(4);
*(.text) /* .text sections (code) */
*(.text*) /* .text* sections (code) */
*(.rodata) /* .rodata sections (constants, strings, etc.) */
*(.rodata*) /* .rodata* sections (constants, strings, etc.) */
*(.glue_7) /* glue arm to thumb code */
*(.glue_7t) /* glue thumb to arm code */
*(.eh_frame)
KEEP (*(.init))
KEEP (*(.fini))
. = ALIGN(4);
_etext = .; /* define a global symbols at end of code */
} >FLASH2
...
But this doesn't work too.
I don't know what's wrong.
I have tried to found out it on internet, but without success.
Here I found out this problem has more people.
Can you help me how to allocate variable array to Sector1 in Flash
and how to prohibit this sector to other flash data?
#linker2012-08-07 08:34 PM
I'll have to look at the ELF/HEX, but it sounds more like a problem with the tool uploading the code.
2012-08-09 06:28 AM
It does indeed work, if I load the code via USB, and ignore the debugger. Must be something in my Eclipse/GDB Server/ST-Link installation and/or setup.
Thanks!!2013-02-28 08:28 AM
Hi clive1,
I'm programming a Bootloader for the stm32f4. In it I'm using the eeprom emulation to store some variables
I have already create a sector in my linker file. Same as your example I'm using the sector1. Everything works fine just that its quite a pity not to use the 16k from sector0 completely. I have found that with the c28x can combine two blocks with the following definition: SECTIONS { .text: { *(.text) } >> FLASHE| FLASHH } described here: http://processors.wiki.ti.com/index.php/C28x_Compiler_-_Understanding_Linking I have try it with the GNU linker without success.I can include in the sector0 manually some code as you did with the handler pointers
and some files like
data.o(.data)
But I dont like this solution since what I want is to use completely the sector0 and sector2 for my bootloader.
do you have any idea if its possible to do this?
Regards
2013-02-28 10:20 AM
My boot loader target is about 14-15KB, so it fits in a single block.
I'm not sure the GNU linker is particularly well suited to embedded applications where sections can span or be sparse. You might need to get really clever with the linker script, or modify the linker to suit. Generally I'd recommend backfilling the first sector with things you know will fit, and fit together. You should be able to steer object files, sections or functions to specific regions. The linker will error if you exceed capacity. To the best of my knowledge there isn't a quick/simple way to handle voids, or enable spanning automatically, and you will have to do some manual fitting to improve utilization. I'm not a GNU/GCC expert, others may have tackled this.2013-03-01 02:28 AM
Thank you for your answer clive1,
I found that this feature is currently not supported as explained here: regards.2013-03-01 03:32 AM
One possible vector for automation would be a two pass approach using AWK (or scripting language of choice) to digest the .MAP and .LD files and produce a new linker script with an optimal mapping of functions to sections.
2014-06-16 02:22 AM
Hello, I'm using ARM GCC and I'm trying to use linker script as below:
MEMORY
{
FLASH_ISR_TABLE (rx) : ORIGIN = 0x8000000, LENGTH = 16K
FLASH_DEV_DESC (rx) : ORIGIN = 0x8004000, LENGTH = 16K
FLASH (rx) : ORIGIN = 0x8008000, LENGTH = 1024K - 32k
CCMRAM (rwx) : ORIGIN = 0x10000000, LENGTH = 64K
RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 128K
}
SECTIONS
{
.isr_vector :
{
KEEP(*(.isr_vector))
} > FLASH_ISR_TABLE
.device_desc :{
KEEP(*(.device_descriptor))
} > FLASH_DEV_DESC
.text :
{
*(.text*)
KEEP(*(.init))
KEEP(*(.fini))
/* .ctors */
*crtbegin.o(.ctors)
*crtbegin?.o(.ctors)
*(EXCLUDE_FILE(*crtend?.o *crtend.o) .ctors)
*(SORT(.ctors.*))
*(.ctors)
/* .dtors */
*crtbegin.o(.dtors)
*crtbegin?.o(.dtors)
*(EXCLUDE_FILE(*crtend?.o *crtend.o) .dtors)
*(SORT(.dtors.*))
*(.dtors)
*(.rodata*)
KEEP(*(.eh_frame*))
} > FLASH
....
....
....
In the map file I look up the
__isr_vector
:.isr_vector 0x08000000 0x18c
*(.isr_vector)
.isr_vector 0x08000000 0x18c ./Src/startup_STM32F40XX.o
0x08000000 __isr_vector
.device_desc 0x08004000 0x18*(.device_descriptor)
.device_descriptor
0x08004000 0x18 ./Application/SKP4_revA_Main/SKP4_MainApp.o
.text 0x08008000 0x36678
*(.text*)
...
...
...
At this stage everything looked ok (at least for me:) ) But when I checked hex and bin file the __isr_vector was missing. (Output files started from string descriptor which I put in .device_descriptor section. This section start from address: 0x8004000)
When I modified
isr_vector section as follow:
.isr_vector :
{
KEEP(*(.isr_vector))
*(.text.SD*)
*(.text.*Handler)
}
> FLASH_ISR_TABLE
Problem disappear. Output files starts from ISR table as they should. And program runs under debugger without any problems.
Any ideas why linker is removing
isr_vector section even if its marked as
KEEP???
2014-06-16 08:05 AM
Any ideas why linker is removing isr_vector section even if its marked as KEEP???
No, I'd need to know the version of the tools involved, and to see the MAP/ELF/HEX/BIN files produced, to have the remotest idea what's going on in this situation.2014-06-17 08:15 AM
I'm using ARM GCC (GNU Tools ARM Embedded) in version 4.8 2013q4 (I also tested it with newest version - 4_8-2014q2, with the same result)
Please find the attached files (I enclosed map, bin, hex and linker script). Thanks for help. ________________ Attachments : skp4_ld_test.bin : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I1AO&d=%2Fa%2F0X0000000bjF%2F7VXNQLtHciXqKI4BX5y.GLr1RtuyLBp0iSdOdz0eIDk&asPdf=falseskp4_ld_test.hex : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I1AJ&d=%2Fa%2F0X0000000bjD%2FxA5suxut3idlJT3ycvsBjKtGYKytamG9.0Mtg9ESJYc&asPdf=falseskp4_ld_test.map : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I1A9&d=%2Fa%2F0X0000000bjC%2F8qpsvolv9o24_h2mpgXMQDz5mT4RuwZJn3uTWc9n_M0&asPdf=falseSTM32F407VG.ld : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I18t&d=%2Fa%2F0X0000000bj8%2FTThA114jCCQYdAkxE5gEIMjMf09kKZylAIHm.yRBGc0&asPdf=false2014-06-17 08:37 AM
The ELF file has the meta-data I'm most interested in. Please attach that. Thanks.