Adding an uninitialized data section to a GCC build?

[infoinfo989]

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

[Tesla DeLorean]

Posted on June 13, 2014 at 13:34

i want to use the ccm (stm32f407) at the keil uVision , but i did't find the way how to write the scatter file ? could you give me a way how to use the ccm in the keil ?

This creates a .ccm section, and also directs the STACK section from a specific object into CCM to demonstrate. Review the .MAP file to confirm memory placements.

; *************************************************************
; *** Scatter-Loading Description File generated by uVision ***
; *************************************************************
LR_IROM1 0x08000000 0x00100000 { ; load region size_region
ER_IROM1 0x08000000 0x00100000 { ; load address = execution address
*.o (RESET, +First)
*(InRoot$$Sections)
.ANY (+RO)
}
RW_IRAM1 0x20000000 0x00020000 { ; RW data
.ANY (+RW +ZI)
}
RW_IRAM2 0x10000000 0x00010000 { ; CCM
startup_stm32f4xx.o (STACK)
*(.ccm)
}
}

char buf[256] __attribute__ ((section(''.ccm'')));

[guoruipang]

Posted on June 14, 2014 at 02:54

Dear clive1 ,

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

[ralf2]

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]

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.

[ralf2]

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]

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-