Hello,I want to keep some variables in my code at certain addresses. For this, I created a new section in the LD file to reserve a certain area from the existing FLASH memory. I wait for the variable I created by typing __attribute__((section(".flash_rw.__at_0x000...))) to write to the address I specified. However, it writes the value to a completely different address in the section I created. I use arm-none-eabi-. GNU Arm Embedded Toolchain version 10 2021.10.
MEMORY { FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0x40000 /* 256 KB ana Flash bellek */ FLASH_RW (rx) : ORIGIN = 0x00040000, LENGTH = 0x40000 /* 256 KB yazılabilir Flash bellek */ RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 0x18000 /* 96 KB RAM */ }
SECTIONS { .... .... .... .... .flash_rw : { . = ORIGIN(FLASH_RW); __flash_rw_start__ = .; *(.flash_rw) *(.flash_rw.*) . = ALIGN(4); __flash_rw_end__ = .; } > FLASH_RW
unsigned short tristor50x35[584] __attribute__((section(".flash_rw.__at_0x0006A4CA"))) = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x820, 0x842, 0x842, 0x842, ........ };
The output of the code is as follows;
Flash Address tristor50x35 => 0x00057b70
First of all, in the situation that I mentioned in my last article, the icons were not appearing on the TFT screen.
//icons.h #define _STRINGIFY(x) #x #define STRINGIFY(x) _STRINGIFY(x) #define _CONCATPREFIX(y) __arm_at_##y #define ARM_AT_ADDR(y) STRINGIFY (_CONCATPREFIX (y)) #define ADDR50X35 0x0006A4CA
//icons.c unsigned short __attribute__((section(ARM_AT_ADDR (ADDR50X35)))) tristor50x35[584] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x820, 0x842, 0x842, 0x842, . . . };
I ran the command you said and created a new ld file. and I use this as linker but =>
ignoring invalid character `\377' in expression ignoring invalid character `\376' in expression ignoring invalid character `\000' in expression
I am getting error like this.
ASSERT(__StackLimit >= __HeapLimit, "region RAM overflowed with stack") .flash_rw : { . = ORIGIN(FLASH_RW); __flash_rw_start__ = .; *(.flash_rw) *(.flash_rw.*) . = ALIGN(4); __flash_rw_end__ = .; } > FLASH_RW .abs_tristor50x35 ADDR50X35 : { *(ARM_AT_ADDR(ADDR50X35)) } }
Sadly I have no idea what those "invalid character" error messages are! Did you #include <icons.h> in your LD script before preprocessing it?I would expect the " .abs_tristor50x35 ADDR50X35 : { *(ARM_AT_ADDR(ADDR50X35)) }" line to now feature the 0x0006A4CA after preprocessing
First of all, when preprocessing as lscript.ld, it gives an error because #include "icons.h" cannot be found. So I changed the extension of the ldscript.ld file to ldscript.c. Likewise, there is the #include section at the beginning and under it are the linker script settings. The command I just ran is
arm-none-eabi-gcc -P -E ldscript.c > ldscript.ld
However, after this command, I received an invalid character error. this is because a problem with encoding. To solve this, I changed the command like this
arm-none-eabi-gcc -P -E ldscript.c | % {$_ -replace "`r`n","`n"} | Out-File -Encoding ascii ldscript.ld
and the problem was solved. However, I could not run it with #define's as you said. Instead, addresses are defined one by one in the ldscript.c file, and the preprocessing process must be repeated for each address change.
// ldscript.c file #include "icons.h" #define tristor50x35 0x65C00 MEMORY { FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0x40000 /* 256 KB */ FLASH_RW (rx) : ORIGIN = 0x00040000, LENGTH = 0x40000 /* 256 KB */ RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 0x18000 /* 96 KB */ } SECTIONS { //other parts .flash_rw : { //flash_rw section } > FLASH_RW .abs_tristor50x35 tristor50x35 : {*(.flash_rw.__at_tristor50x35)} }
ld file created after preprocessing;
.flash_rw : { . = ORIGIN(FLASH_RW); __flash_rw_start__ = .; *(.flash_rw) *(.flash_rw.*) . = ALIGN(4); __flash_rw_end__ = .; } > FLASH_RW .abs_tristor50x35 0x65C00 : { *(.flash_rw.__at_tristor50x35 ) }
Ok, interesting. There definitely must be something funky going on with your editor or operating system for the non-ascii characters to be creeping in. I suspect if you find out what that is and that all files start with the correct ASCII characters, then the on-the-fly replace and encoding change won't be needed.Another tip:"-x c " If you add that to your command line to the preprocessor it tells it to treat the input file as C code, regardless of the file extension. Then you won't need to go through renaming to ldscript.c.
What I was aiming for is a world where:* icons.h contains the definitions for STRINGIFY, ARM_AT_ADDR, etc. and all the address definitions, e.g. "#define tristor50x35 0x65C00"
* your original ld script only #includes icons.h. It then uses the preprocessor macros in the SECTIONS command.
* your C code also only #includes icons.h and uses the preprocessor macros in the __attribute__(section)).The benefit of this is that you end up defining the addresses in one place, rather than in multiple places. As such, you can more easily move things around in the memory map, and you have less of a maintenance burden when you want to change something