Skip to main content
infoinfo989
Associate III
December 22, 2011
Question

Adding an uninitialized data section to a GCC build?

  • December 22, 2011
  • 15 replies
  • 6007 views
Posted on December 22, 2011 at 07:18

Perhaps the subject line is a bit cryptic, but does anybody know how to add uninitialized data sections to the linker script? The F4xx has two RAM banks. I want to use the smaller 64 kB as the normal RAM area (.bss etc) and the larger 128 kB RAM as an area for large data buffers, which would be declared using the __attribute__ in the C code. Here's what I've done...

In the linker script:

MEMORY
{
RAM_C (xrw) : ORIGIN = 0x10000000, LENGTH = 64K
RAM_D (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 1024K
}

and also

/* This is the 128 kB RAM, used for data buffers that require DMA access. This RAM is not used by default - 
 the programmer
must explicitly specify using this RAM by something like: 
 uint8_t mybuffer[1024] __attribute__((section(''.buffram''))); 
Also, the programmer should NOT assume this RAM will be initialised at boot. */
.buffram:
{
. = ALIGN(4);
*(.buffram) /* .buffram section */
. = ALIGN(4);
} >RAM_D

Then in my C code I do (for example): volatile uint8_t buff0[16384] __attribute__((section(''.buffram''))); It's all great, everything compiles and links OK, no problems in that regards. BUT... The output hex file is huge. Because it contains a 64 kB section of .buffram section, all zeros. Put another way, it's kinda like it's treating this new data section as flash, in that it's putting it into the output hex file. I've been googling and reading LD documentation like crazy, but I'm missing some magic trick here. How do I keep this data section out of my hex file? Thanks. #problem-solved #corrupted-parameters #i-hate-this-word(tm)-editor #ccm
    This topic has been closed for replies.

    15 replies

    guoruipang
    Associate
    June 14, 2014
    Posted on June 14, 2014 at 02:54

    Dear clive1 ,

    thank you for your response ,it works now, thank you.

    ralf2
    Associate
    August 30, 2014
    Posted on August 30, 2014 at 18:57

    Hello i have a similar problem:

    In my source there are defined some tables of char for Fonts of my LCD

    Now there came up a problem: At a point of codesize my parameters to functions where corrupted. I detected when the pointer of the parameter was lower than 0x8010000 all is well but at this magic limit my parameters seem to be 0xff ...

    So i thought a further segment would help and i added a segment FONT to my linker script:

    MEMORY

    {

        FLASH (RX) : ORIGIN = 0x08000000, LENGTH = 384K

        FONT  (RX) : ORIGIN = 0x08060000, LENGTH = 128K

        SRAM (RWX) : ORIGIN = 0x20000000, LENGTH = 64K

    }

     

    i propagated it:

    and changed the definition of the table:

    const uint8_t DroidSans_Bold_20_Table[]__attribute__((section(''.font''))) = {..........

    after that, the program does it´s work nearly perfect, but now the table returns 0xff and so there is no Font on my display....

    are the datapointers too short?

    MCU is stm32f103VET6 Compiler gcc-arm-none-eabi 4.8    using Visual GDB and ST-LinkV2

    do you have an Idea?

    Tesla DeLorean
    Guru
    August 30, 2014
    Posted on August 30, 2014 at 19:11

    do you have an idea?

    I have many...

    You'd need to look at the SECTIONS portion, and how you've created those, and directed content into them.

    Suggest you attach the current linker script so I can better understanding of your specific context. You could also look at what I did with CCM and .ccm earlier and apply those ideas more completely to your problem/issue.

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    ralf2
    Associate
    August 30, 2014
    Posted on August 30, 2014 at 19:24

    Hello,

    at first thank you for your answer.

    well, i attach the script.

    sorry but i have no idea, i think for 2 days about the problem but there´s nothing in my mind what is wrong.

    ________________

    Attachments :

    STM32F103xE_flash.lds : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I1Fp&d=%2Fa%2F0X0000000bll%2FVgeXUX18yQR4aB_OKYIR0BjExT9gHTj0TGaYskNowOg&asPdf=false
    ralf2
    Associate
    August 31, 2014
    Posted on August 31, 2014 at 16:04

    Hello,

    i am lucky to tell you that the problem is solved.

    I searched at an absolutely false end.

    a definition in my eeprom handling was the ''Bug'':

    /* EEPROM start address in Flash */

    #define EEPROM_START_ADDRESS    ((uint32_t)0x08010000) /* EEPROM emulation start address:

                                                      after 64KByte of used Flash memory */

    was not intendet to use with my VE MCU.

    I made the correct definition and all ''ghosts'' dissapeared.

    have a nice day and thanks for your effort.

    -Ralf-