Defining Variables at Absolute Addresses with gcc

Posted on November 1, 2012 by Erich Styger

Many compilers offer a way to allocate a variable at an absolute address. For example for the Freescale S08 compiler, I can place my variable at a given address:

unsigned char buf[128]@0x2000;

This is very useful (and needed) e.g. if the hardware (like USB) needs a buffer at given address. The advantage of the above (non-ANSI and thus not portable) syntax is that I can define a variable at an absolute address, without the need to allocate it in the linker.

I wanted to do something similar with gcc for Kinetis/ARM, and searched many forums on the internet. Obviously, I’m not alone with this question. The solution I have found comes close to what I use e.g. for the S08 compiler.

How can I place a variable say at address 0x2000’0000 with gcc for ARM/Kinetis?

The idea I use here is to put the variable with a special section name, and then place it in the linker file at an absolute address.

💡 I have not found a way to place a variable at an absolute address *without* to modify the linker file? Post a comment if you know a better solution!

attribute

Gcc uses the __attribute__ keyword as a way to ‘mark’ variables with special attributes. It allows me put my variable into a special section, which I name here ‘.myBufSection’:

unsigned char __attribute__((section (".myBufSection"))) buf[128];

Another useful thing is: I can specify the alignment of that variable with an __attribute__ too:

unsigned char __attribute__((section (".myBufSection"))) buf[128] __attribute__ ((aligned (512)));

With this, my variable will be put into a section named ‘.myBufSection’, and it will be aligned on a 512 address boundary.

Absolute Section Placing in Linker File

The next step is to place that section at an address in the linker file. E.g. for the KL25Z of my Freedom board, I have this memory mapping in my linker file:

MEMORY
{
  m_interrupts  (rx) : ORIGIN = 0x00000000, LENGTH = 0xC0
  m_cfmprotrom  (rx) : ORIGIN = 0x00000400, LENGTH = 0x10
  m_text        (rx) : ORIGIN = 0x00000800, LENGTH = 128K - 0x800
  m_data       (rwx) : ORIGIN = 0x1FFFF000, LENGTH = 16K
}

I could split my m_data block and create my memory block for my variable to place at 0x2000’0000. An easier way is to simply place my section from above into the SECTIONS block like this:

SECTIONS
{
  /* placing my named section at given address: */
  .myBufBlock 0x20000000 :
  {
    KEEP(*(.myBufSection)) /* keep my variable even if not referenced */
  } > m_data

  /* other placements follow here... */
}

With above linker statement, I define an absolute start address for all my variables in the section named .myBufSection, and place it into the m_data memory block. Additionally I need to use the KEEP keyword to tell the linker *not* to dead-strip my variable, in case I do not reference it from my code.

Checking the Allocation

After linking, now my object should be at the given address. While looking at the linker map is always a good idea, I have found another nice tool which comes with the GNU suite: nm. With nm I can examine binary files like the ELF file produced by the linker. In CodeWarrior for MCU10.3, that command line utility can be found in

<CW installation path>\Cross_Tools\arm-none-eabi-gcc-4_6_2\bin\arm-none-eabi-nm.exe

I could configure to run it as post-link step in CodeWarrior, or simply use it from the DOS command line prompt:

nm shows my variable at the absolute address

Summary

For gcc, placing a variable at an absolute address requires two steps: marking it with a section name in the source, and then placing it in the linker file at an absolute address.

It would be good if there would be a way to avoid the linker file change, but I have not found another or better solution.

Happy Absoluting 🙂

76 thoughts on “Defining Variables at Absolute Addresses with gcc”

Bill Lewis on November 1, 2012 at 22:16 said:

Erich,
You are amazingly prolific!
-Bill

LikeLike

Reply ↓
- Sandro on November 5, 2014 at 14:08 said:
  
  Hello Erich,
  first of all thanks for the good solution!
  I would like to ask this: if I need to create more than one variables ( I need few arrays..), have I to declare a section for each array? Or there is easier way, using code instead of adding more sections?
  
  Thanks!
  
  LikeLike
  
  Reply ↓
  - Sandro on November 5, 2014 at 14:28 said:
    
    I put the question in the wrong place sorry…
    
    LikeLike
    
    Reply ↓
    - Paul Madle on September 24, 2020 at 11:07 said:
      
      Nope… You could use the same __attribute__((section(….)) for both…
      
      LikeLike
Barrie Campbell on November 26, 2012 at 23:46 said:

*(volatile unsigned char *)(IO_BASE + 0x00)

LikeLike

Reply ↓
- Erich Styger on November 27, 2012 at 04:37 said:
  
  Hi Barrie,
  yes, using a casted pointer is the preferred way to access peripherals. The problem with this is that it is only accessing an object, but not defining it. In my case I want to reserve memory for it, not only accessing it. and if it is just such a pointer access, that will not work.
  Erich
  
  LikeLike
  
  Reply ↓
mikaelnelson on February 14, 2014 at 17:10 said:

Is there any way of doing this while allowing Processor Expert to generate the linker file itself? I’ve had to disable “Generate Linker File” in order to maintain the modification to the linker file. Not a big deal, just curious if it’s possible. I didn’t see anything while looking through PE.

LikeLike

Reply ↓
- Erich Styger on February 14, 2014 at 17:13 said:
  
  No, I have not found another way for this neither. I had to disable linker file generation too.
  
  LikeLike
  
  Reply ↓
Pingback: GNU Linker, can you NOT Initialize my Variable? | MCU on Eclipse
RobertoM on July 28, 2014 at 09:21 said:

Hi Erich, I’m looking for a DoOnStack equivalent for Kinetis and Google redirects here. Do you know if a DoOnStack equivalent routine exist? Thank you

LikeLike

Reply ↓
- Erich Styger on July 28, 2014 at 09:24 said:
  
  Hi Roberto,
  you mean the equivalent of AN3942 for Kinetis?
  
  LikeLike
  
  Reply ↓
  - RobertoM on July 28, 2014 at 11:59 said:
    
    yes 🙂
    
    LikeLike
    
    Reply ↓
    - Erich Styger on July 28, 2014 at 14:48 said:
      
      I don’t have that, I guess it just would be a few hours of work 🙂
      
      LikeLike
shurik on September 1, 2014 at 06:11 said:

Eric,

i am using your post for embedding a version inside the output file.
i did as you have described:
in the linker script:
.myBufBlock 0x00000000 : {
KEEP(*(.myBufSection))
} > DDR2_SDRAM_MEM_BASEADDR

in the code:
int __attribute__((section (“.myBufSection”))) SWVersionInFile = 0x0306060A; // 3.6.6.10

the problem that in the output file itself, the data is placed as ASCII and not as its value.
meaning that the values looks like that:
30 33 30 36 30 36 30 41
instead of::
03 06 06 0A

Where is the problem?
Thanks.

LikeLike

Reply ↓
- Erich Styger on September 1, 2014 at 11:48 said:
  
  Hi shurik,
  hmm, that’s really strange. I tried to replicate this, and added this to my .text section:
  .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(*(.myBufSection))
  KEEP (*(.init))
  KEEP (*(.fini))
  . = ALIGN(4);
  } > m_text
  but for me the result was as expected (0x306060a). Could it be that you look at the wrong variable? Can you verifiy in the linker map file that your variable has indeed be linked (and not be removed by the linker as not used?).
  
  LikeLike
  
  Reply ↓
Matthijs van Duin on September 18, 2014 at 01:12 said:

Simpler solution: just declare the variable as extern and assign an absolute value to that symbol in your linker script.

LikeLiked by 1 person

Reply ↓
- Erich Styger on September 18, 2014 at 06:55 said:
  
  Can you share such an symbol entry in your linker script?
  
  LikeLiked by 1 person
  
  Reply ↓
  - Matthijs van Duin on September 18, 2014 at 15:19 said:
    
    SECTIONS {
    buf = 0x20000000;
    /* other stuff */
    }
    
    LikeLike
    
    Reply ↓
    - Erich Styger on September 18, 2014 at 20:57 said:
      
      That’s indeed very simple, I had not considered this, thanks for sharing!
      
      LikeLike
  - Matthijs van Duin on September 18, 2014 at 15:27 said:
    
    See also https://sourceware.org/binutils/docs-2.24/ld/Assignments.html
    
    LikeLike
    
    Reply ↓
    - Erich Styger on September 18, 2014 at 20:59 said:
      
      Thanks, that link helps even better to understand how it works 🙂
      
      LikeLike
  - Matthijs van Duin on July 24, 2015 at 07:36 said:
    
    Actually I discovered it’s even simpler: you can just put a bunch of assignment statements in a file and pass it to the linker as if it’s an object file. This works regardless of whether you also have a custom linker script, and you can pass multiple of such files if you wish.
    
    LikeLike
    
    Reply ↓
Tom on September 30, 2014 at 02:47 said:

Erich should write all the Kinetis docs. This is great.

LikeLike

Reply ↓
Sandro on November 5, 2014 at 14:43 said:

Hello Erich,
first of all thanks for the good solution!
I would like to ask this: if I need to create more than one variables ( I need few arrays..), have I to declare a section for each array? Or there is easier way, using code instead of adding more sections?

Thanks!

LikeLike

Reply ↓
- Sandro on November 5, 2014 at 15:15 said:
  
  Found it 🙂
  u simple declare the second array just after the first one, with the same __attribute__((section (“.myBufSection”))).
  The linker will put the second array in the location just after the first one.
  
  LikeLike
  
  Reply ↓
  - Matthijs van Duin on November 5, 2014 at 16:51 said:
    
    I do not believe that there’s any guarantee that they will end up in memory in source-order. See however my (simpler) alternative method in the comments above; you can just do
    buf = 0x20000000;
    buf2 = buf + 0x1000;
    or whatever. BTW, I put them in a SECTIONS { } block above, but that actually turns out to be optional. You can just put assignments like those in a text file named “whatever.ld” and provide it to ld or even to gcc as a source file (or rather, it is treated as an object file of a slightly strange sort).
    
    LikeLike
    
    Reply ↓
    - Manuel Malagon on November 13, 2019 at 15:25 said:
      
      For having the variables in the same source order you can use a structure. And if you want them on the same order and without wasted space because of padding then you can use a PACKED structure. That way you guarantee the order along with the position in memory.
      
      LikeLike
Alexander Nikitenko on November 14, 2014 at 11:14 said:

Thank you very much, it is very helpful!

LikeLike

Reply ↓
acutetech on May 1, 2015 at 18:42 said:

I wonder if I can use this technique so I can make use of the 832-byte memory area in the KL05 that occupies the space between the end of the m_interrupt area at address 0xc0 and the 16-byte “Flash Configuration Field” – fixed at address 0x400. This appears to be wasted. Can I set m_text start address to 0xc0 simply tell the linker to place the Flash Configuration Field (defined as _cfm[] in Cpu.c) at 0x400?

I tried to copy your example and ended up with _cfm correctly at 0x400, but none of the space between 0xc0 and 0x400 was used.

LikeLike

Reply ↓
- Erich Styger on May 1, 2015 at 20:23 said:
  
  Yes, I think you should be able to do this, but have not done this myself.
  
  LikeLike
  
  Reply ↓
Jesari on June 25, 2015 at 14:46 said:

An example for ARM:

asm (“.set mivar, 0x1234”);
extern int mivar;

main(int argc, char **argv)
{
mivar=0x4567;
}

This is the code generated:

00008018 :
8018: e59f2008 ldr r2, [pc, #8] ; 8028
801c: e59f3008 ldr r3, [pc, #8] ; 802c
8020: e5832000 str r2, [r3]
8024: e12fff1e bx lr
8028: 00004567 .word 0x00004567
802c: 00001234 .word 0x00001234

LikeLike

Reply ↓
- Erich Styger on June 25, 2015 at 14:50 said:
  
  Hi Jesari,
  oh wow, that’s a VERY neat way of doing this! Thanks for sharing!
  
  LikeLike
  
  Reply ↓
  - Jesari on June 25, 2015 at 15:11 said:
    
    You’re welcome.
    BTW, you may also consider to include the following asm line if you’re going to reference the absolute variable from a different source file:
    
    asm (“.global mivar”);
    
    The main problem I’m seeing with this solution is the lack of portability due to the different assembler directives for other architectures.
    
    LikeLike
    
    Reply ↓
- bigjosh2 on January 23, 2023 at 23:05 said:
  
  What an ugly hack, but so easily solves all problems of making constant values computed using a C++ `constexpr` usable in ASM code by passing them though the linker. Thanks!
  
  For others in the future, some versions of gcc also provide `#pragma LOCATION(address)` and/or `__attribute__((location(address)))` to specify the address to put a variable, which is slightly cleaner if available….
  
  https://downloads.ti.com/docs/esd/SLAU132/the-location-pragma-stdz0559880.html
  
  LikeLike
  
  Reply ↓
  - Erich Styger on January 24, 2023 at 19:04 said:
    
    I agree, that __attribute__((location(address))) would be the way to go. But so far I have seen this only in the TI version of gcc, and not for other architectures?
    
    LikeLike
    
    Reply ↓
    - bigjosh2 on January 24, 2023 at 20:23 said:
      
      Correct, I have not seen it anywhere else besides the TI compiler and even there it is proving to be quite flakey. Sometimes code will compile and link with no errors or warnings, but the variable will inexplicably end up at address `0x0001`.
      
      Sadly in my case I think I am going to have to resort to code-that-writes-code; write a C++ program that emits ASM source with hard coded address constants which is then assembled into an OBJ that is linked back into the final program. Not happy about it though.
      
      LikeLike
    - Erich Styger on January 26, 2023 at 08:16 said:
      
      Using the __attribute__((section (“.mysectionName”))) worked very well for me. So far I have just tweaked the linker file for it, and that was not hard. I was considering writing a small script to make a linker script file I could include into the linker script, but so far it was easier to do it by hand.
      
      LikeLike
Larry Carter on August 18, 2015 at 00:38 said:

Thanks for the information. I tried both methods above and my variable is indeed at the location I want, however the linker also put another variable at the same location. This is verified by seeing the other variables address in both the map file as well as in the watch window. Any suggestions?

LikeLike

Reply ↓
- Erich Styger on August 18, 2015 at 12:17 said:
  
  Hi Larry,
  you would need to exclude that memory area in your linker script file.
  
  LikeLike
  
  Reply ↓
  - cai on September 28, 2016 at 15:49 said:
    
    Hi Erich,
    I have meet same question, could you tell me how to exclude that memory area. I have search in some link script document, but could not find the answer.
    
    LikeLike
    
    Reply ↓
    - Erich Styger on September 28, 2016 at 17:12 said:
      
      Hi cai,
      Have a look at the MEMORY section in the linker file: you can reduce the section size and create additional sections.
      Erich
      
      LikeLike
Ganesh R on February 19, 2016 at 09:25 said:

Hey Erich
Awesome Solution. Now We know how to place a variable in a specific location. But If I want to place a piece of code in a specific memory address. What should I do ?

unsigned int i;
for(;;){
Bit1_ClrVal(); // passing ‘0’ to CR1 LED port

for(i=0;i<=1000000;i++); //software delay

Bit1_SetVal(); // passing '1' to CR1 LED port

for(i=0;i<=1000000;i++); //software delay

}
I want to put this code into the flash memory area of my KINETIS E series controller (MKE02Z64VLD2). Flash region is 0X0000_0000 to 0X07FF_FFFF. Can u say how it is done ?
Thanks
Regards
Ganesh R

LikeLike

Reply ↓
- Erich Styger on February 19, 2016 at 09:56 said:
  
  Hi Ganesh,
  the easiest way is to do this in the linker file, and per file. See https://mcuoneclipse.com/2014/10/06/putting-code-of-files-into-special-section-with-the-gnu-linker/
  Otherwise you need to mark each function with a section attribute and then handle it in the linker file.
  
  Erich
  
  LikeLike
  
  Reply ↓
Elias on June 29, 2016 at 05:43 said:

Thanks a ton for this post! I need to be able to reprogram data in non-volatile memory, and my chip can only do that 4kB at a time. I can’t mess with the execution instructions that the data used to be mixed in with, so I can’t just use an absolute pointer as others suggested. I need a section of ROM that I know I can mess with without interrupting operation of the device.

LikeLike

Reply ↓
- Erich Styger on June 29, 2016 at 08:01 said:
  
  Yes, depending on the FLASH technology 1, 2, 4, 8 or more are in a block/sector. I have used sucessfully used the approach I have described in https://mcuoneclipse.com/2014/05/31/configuration-data-using-the-internal-flash-instead-of-an-external-eeprom/
  
  LikeLike
  
  Reply ↓
Geoff S on October 31, 2016 at 13:42 said:

Erich, is there a way to get the base address for a section that is defined in the linker script (like the .myBufSection you created in your example above), if for example, you wanted to read a few bytes starting from the beginning of this section ?

LikeLike

Reply ↓
- Erich Styger on November 1, 2016 at 07:17 said:
  
  Hi Geoff,
  yes, there should be a way, at least for the section name, maybe with an additional label in the linker script. I’m travelling today, but I see in the evening/tonight if I could write up something small on that topic.
  Erich
  
  LikeLike
  
  Reply ↓
- Erich Styger on November 2, 2016 at 05:09 said:
  
  to close the loop: new article published on that topic: https://mcuoneclipse.com/2016/11/01/getting-the-memory-range-of-sections-with-gnu-linker-files/
  
  LikeLike
  
  Reply ↓
Pingback: Accessing GNU Linker Script Symbols from C/C++ | MCU on Eclipse
Pingback: Flash-based Configuration Data Using The ld Linker – vilimblog
mondalaciugl on June 3, 2017 at 23:03 said:

I have two comments to add:

1. Given this code:

unsigned char __attribute__((section (“.myBufSection”))) buf[128] __attribute__ ((aligned (512)));

I think it can be written in a shorter manner by separating the attributes with a comma:

unsigned char __attribute__((section (“.myBufSection”), aligned (512))) buf[128];

2. By using the “used” attribute, GCC is explicitly told not to dead-strip the variable when not referenced. I think it’s similar to the KEEP() directive of link scripts:

void __attribute__ ((used, section (“.init3”), naked)) move_sp(void) {…}

LikeLike

Reply ↓
- Erich Styger on June 4, 2017 at 08:19 said:
  
  Yes, __attribute__ settings can be combined, but sometimes they have be before or after a declaration. I have not checked in that particular case if both can be before the declaration.
  The used attribute is something too, but to my knowledge it is working for functions only, but not for variables. That way the KEEP inside the linker script is very useful.
  
  LikeLike
  
  Reply ↓
  - mondalaciugl on June 4, 2017 at 23:46 said:
    
    Thanks for the correction on both accounts, Erich! It’s always great to learn new stuff from you. 🙂
    
    LikeLike
    
    Reply ↓
Dirk on July 5, 2017 at 12:05 said:

Thank you very much Erich! This is a great thing and helps a lot! I’ve tested it with success in debug mode. If I switch to Release it doesn’t work any more. I found out the reason: Debug Setting -> Optimization Level: None, Release Setting -> Optimization Level: Optimize for size. If I change this in Release mode it works well again. But I have bigger code-size. I thought the KEEP instruction in the linker script would prevent this? Or am I doing something wrong?
Regards, Dirk

LikeLike

Reply ↓
- Erich Styger on July 5, 2017 at 14:30 said:
  
  Hi Dirk,
  strange, it works for me regardless of optimization level. Maybe it depends on the GNU compiler version (have not checked), but in KDS it works with GNU ARM Embedded 4.8 Q3 2014.
  You might have a look at one of my example projects, e.g. https://github.com/ErichStyger/mcuoneclipse/tree/master/Examples/KDS/FRDM-KL03Z/FRDM-KL03Z_LED. The variable bootloader_config_t inside the bootloader_config.c is preserved.
  
  LikeLike
  
  Reply ↓
  - Dirk on July 6, 2017 at 07:01 said:
    
    Hello Erich, thank you for your reply. I have already looked into your source code, but have not yet come across something that helped. The development environment is Infineon DAVE 4.3.2 (ARM-GCC-49). The Device: XMC4500. I will continue looking for a solution. If I have it, set it here as well. Thanks, Erich! Regards, Dirk
    
    LikeLike
    
    Reply ↓
Pingback: Getting Started: ROM Bootloader on the NXP FRDM-KL03Z Board | MCU on Eclipse
Pingback: Using Multiple Memory Regions with the FreeRTOS Heap | MCU on Eclipse
isaac on March 7, 2018 at 19:03 said:

A really nice explanation about this topic, I don’t like the method but guess there is not other way to do it. Thanks

LikeLike

Reply ↓
- Erich Styger on March 7, 2018 at 19:21 said:
  
  I’m not aware of any other or better way.
  
  LikeLike
  
  Reply ↓
  - Chris Grant on November 12, 2018 at 05:07 said:
    
    I have also used the flag -fdata-sections and while it still requires linker magic, it avoids the need for the attributes in the source code. It also will allow you to order specific declarations in a section if needed.
    
    LikeLike
    
    Reply ↓
    - Erich Styger on November 12, 2018 at 07:31 said:
      
      The -fdata-sections flag basically means that the linker creates a section name for each variable. That way the name of that section or variable can be used in the linker file. That’s indeed another good approach.
      
      LikeLike
Dreamer on September 9, 2018 at 17:06 said:

Why can’t be simply done like this:
DIM var AS [XRAM/SRAM/ERAM]type [AT location/variable] [OVERLAY]
https://avrhelp.mcselec.com/index.html?dim.htm
I think, Bascom solution is the best and most elegant. Does exist something like this for C – ARM? Is C stupid or me? How to improve C? How to translate such code to C? I start learn C and would really like to hear opinions.

LikeLike

Reply ↓
- Erich Styger on September 9, 2018 at 19:08 said:
  
  That example is with BASIC, and the concepts are really different to the C language. C has a long heritage plus must conform to standards which might be counter intutitive. On the plus side: C (and C++) are close to the hardware so you can know what happens for every line of your program. And you get C for virtually any architecture/CPU/microcontroller where Bascom is more of a nice solution to me? I think you have to go through that learning experience, I’m affraid.
  
  LikeLike
  
  Reply ↓
Pingback: Stack Canaries with GCC: Checking for Stack Overflow at Runtime | MCU on Eclipse
Manuel Malagon on November 13, 2019 at 15:55 said:

If I create a section at the end of .text, this is, if .text is declared having a size of 0x8000 and I “resize” .text to 0x7FC00 (assuming a flash sector of 1K), and create my section starting on 0x7FC00 with a size of 0x400 (1k), is the flashing tool not going to touch this section?

I ask because I want to use this portion of memory at the end of .text to store non-volatile data and it is not desirable at all that the flashing tool would wipe it out, but I’m not sure if I have to do any additional steps or add additional declarations to the linker file or the project to keep the flashing tool from touching this area.

LikeLike

Reply ↓
- Erich Styger on November 14, 2019 at 08:06 said:
  
  If an area is erased or not depends on multiple factors:
  – debug probe: some debug probe will erase the whole device (all sectors), some only the sectors which are part to the binary. Some have a setting to configure this
  – on chip/bootloader: usually you can define which sectors are erased (or protected)
  The linker itself does not control this: all what it does is to build the binary
  
  LikeLike
  
  Reply ↓
Chris Grant on November 14, 2019 at 06:10 said:

That would be flash tool dependant. Some erase the entire chip and some you can specify what range to erase. Even in that case some will erase the chip and then restore the preserved areas back. A linker script change will not necessarily help you here.

LikeLike

Reply ↓
cauan on August 17, 2020 at 21:37 said:

Hi,

How do I write the same thing as this:
”
#pragma location = “OPTBYTE”
__root const char opbyte0 = 0xFF;
#pragma location = “OPTBYTE”
__root const char opbyte1 = 0xF3;
”
but with gcc?

Im trying to build this code in e2 studio but i keep getting a lot of erros
thank you

LikeLike

Reply ↓
- Erich Styger on August 18, 2020 at 09:27 said:
  
  I have not worked with e2 studio recently, but as it uses GNU/gcc you should use the __attribute__ syntax.
  
  LikeLike
  
  Reply ↓
Joe on October 6, 2020 at 23:01 said:

To access a struct at some fixed address, just use a pointer whose value is the address:

struct type_t *varp = (type_t *)0x200000;

I suppose this might not work in some environments but it’s what I do when I need.

LikeLike

Reply ↓
- Erich Styger on October 7, 2020 at 05:44 said:
  
  Hi Joe,
  yes, that’s the normal way for accessing hardware/etc which are already at a fixed address, or if an object has an address. The bigger problem is how to place an arbitrary object at a specific address (not necessarily accessing it).
  
  LikeLike
  
  Reply ↓
papyDoctor on January 14, 2021 at 15:37 said:

Hi,
If the problem is the selection of a RAM region to store a heap (FreeRTOS heap for example), there is a simpler mean with mcuxpresso IDE to do the stuff without writing custom linker script (or changing the generated one).
If for example I have:
uint8_t __attribute__((section (“.mySection”))) ucHeap[ configTOTAL_HEAP_SIZE ];
Then in Project/properties/C/C++ Buid/Settings/MCU Linker/Managed Linker Script, there is “Extra linker script input sections” where in the
“Input section description” field I can put *(.mySection)
“Region” I can select one of my uC region listed
“Section Type” select .bss
Regards,
Olivier

LikeLike

Reply ↓
- Erich Styger on January 14, 2021 at 20:36 said:
  
  Hi Oliver,
  thanks! I’m using the same approach for my FreeRTOS heap allocation where I use an already existing section name by default.
  Good hint about the ability to add your own section that way, I like that!
  Erich
  
  LikeLiked by 1 person
  
  Reply ↓
Alexey Grigorev on April 23, 2022 at 22:51 said:

Thanks for sharing!

LikeLiked by 1 person

Reply ↓
- Erich Styger on April 25, 2022 at 08:28 said:
  
  You are welcome!
  
  LikeLike
  
  Reply ↓