I want to write a library to a specific address in the flash, I have a entire sector for this, than I will calculate crc16 value of that library, I tried to add a new section in linker file but it couldn't work. i am using Atollic Truestudio as IDE and stm32f4 as mcu.
MEMORY
{
FLASH(rx) = : ORIGIN = 0x08020000, LENGTH = 2048K
IP_CODE(x) = : ORIGIN = 0x08060000, LENGTH = 256K
MY_FUNCTION(rxw) = : ORIGIN = 0x080C0000, LENGTH = 128K//section for the library
RAM(rxw) = : ORIGIN = 0x20000000, LENGTH = 192K
MEMORY_B1(rx) = : ORIGIN = 0x60000000, LENGTH = 0K
CCMRAM(rx) = : ORIGIN = 0x10000000, LENGTH = 64K
}
SECTIONS
{
.isr_vector :
{
.=ALIGN(4);
KEEP(*(.isr_vector))
.ALIGN(4);
} >FLASH
.text:
{
.ALIGN(4);
*(.text)
*(.text*)
*(.glue_7)
*(.glue_7t)
*(.eh_frame)
KEEP(*(.init))
KEEP(*(.fini))
.=ALIGN(4);
_etext=.;
} >FLASH
.mysection :
{
.= ALIGN(4);
KEEP(*(.mysection*))
} >MY_FUNCTION
.
.
. so on..
.
.
}
Related
We are having some troubles with variables stored in SRAM and default values.
We are working with a STM32F745ZE micro. We had to define a section for SRAM:
/* Specify the memory areas */
MEMORY
{
ITCM_RAM (rx) : ORIGIN = 0x00000000, LENGTH = 16K /* +MW+ */
/*RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 319K*/
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 64K /* +MW+ DTCM RAM */
RAM_GEN (xrw) : ORIGIN = 0x20010000, LENGTH = 255K /* +MW+ SRAM1 + SRAM2 */
TRACER (xrw) : ORIGIN = 0x2004FC00, LENGTH = 1K /* +MW+ TRACER memory space */
FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 512K
}
(...)
/* Uninitialized data section */
. = ALIGN(4);
.bss :
{
/* This is used by the startup in order to initialize the .bss secion */
_sbss = .; /* define a global symbol at bss start */
__bss_start__ = _sbss;
*(.bss)
*(.bss*)
*(COMMON)
. = ALIGN(4);
_ebss = .; /* define a global symbol at bss end */
__bss_end__ = _ebss;
} >RAM
/* +MW+ SRAM data section */
.ram_gen :
{
. = ALIGN(4);
_sram_gen = .; /* create a global symbol at data start */
*(.ram_gen) /* .data sections */
*(.ram_gen*) /* .data* sections */
. = ALIGN(4);
_eram_gen = .; /* define a global symbol at data end */
} >RAM_GEN
We want to assign default values to some varieables. It works fine for variables not stored in SRAM, but it doesn't work for varaibles stored in SRAM:. Example
static Test_Ram_t testRam = { .value = 1 };
static Test_Ram_Value_t testRamValue __attribute__((section(".ram_gen"))) = { .value = 1 };
static void Test_Ram_Task1(void const *pvParameters)
{
Test_Ram_Printf("Test Ram: START -----------------------------------------------");
Test_Ram_Printf("Test Ram: Pre value: %d %d", testRam.value, testRamValue.value);
testRam.value += 10;
testRamValue.value += 10;
Test_Ram_Printf("Test Ram: Post value: %d %d", testRam.value, testRamValue.value);
osDelay(osWaitForever);
}
If we reboot the application 3 times the application output is:
[10:30:25.002]
[10:30:25.004] Test Ram: START -----------------------------------------------
[10:30:25.005] Test Ram: Pre value: 1 1
[10:30:25.005] Test Ram: Post value: 11 11
[10:30:27.599]
[10:30:27.601] Test Ram: START -----------------------------------------------
[10:30:27.603] Test Ram: Pre value: 1 11
[10:30:27.604] Test Ram: Post value: 11 21
[10:30:29.497]
[10:30:29.500] Test Ram: START -----------------------------------------------
[10:30:29.502] Test Ram: Pre value: 1 21
[10:30:29.503] Test Ram: Post value: 11 31
Varaible testRam, stored in RAM, is assigned the default value in every restart, but varaible testRamValue, stored in SRAM, the value is keeped between reboots.
Does anyone know how to force to assign the default value on every reboot?
I'm wondering if there's a way to obtain the ROM address used to seed the initial value of a RAM variable? Given a statement static uint32_t foo = 0x12345678; the initial value 0x12345678 is present as ROM somewhere to serve as the initial value at &foo. At some point in time I'd like to be able to reset the value of foo to it's initial state.
I could create a second variable const static uint32_t initial_foo = 0x12345678; to use but that will then double the ROM data space needed to store variables for this use case.
Can the offset &foo from the beginning of RAM (or more specifically &_srelocate, see the linker script below) be reliably correlated with one of the symbols in ROM space?
Selected parts of the ARM/GNU C linker v 6.3.1 script are below.
OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
OUTPUT_ARCH(arm)
SEARCH_DIR(.)
/* Memory Spaces Definitions */
MEMORY
{
rom (rx) : ORIGIN = 0x00400000, LENGTH = 0x00100000
ram (rwx) : ORIGIN = 0x20000000, LENGTH = 0x00020000
}
/* The stack size used by the application. NOTE: you need to adjust according to your application. */
__stack_size__ = DEFINED(__stack_size__) ? __stack_size__ : 0x3000;
__ram_end__ = ORIGIN(ram) + LENGTH(ram) - 4;
SECTIONS
{
.text :
{
. = ALIGN(4);
_sfixed = .;
KEEP(*(.vectors .vectors.*))
*(.text .text.* .gnu.linkonce.t.*)
*(.glue_7t) *(.glue_7)
*(.rodata .rodata* .gnu.linkonce.r.*)
*(.ARM.extab* .gnu.linkonce.armextab.*)
/* Support C constructors, and C destructors in both user code
and the C library. This also provides support for C++ code. */
. = ALIGN(4);
KEEP(*(.init))
. = ALIGN(4);
__preinit_array_start = .;
KEEP (*(.preinit_array))
__preinit_array_end = .;
. = ALIGN(4);
__init_array_start = .;
KEEP (*(SORT(.init_array.*)))
KEEP (*(.init_array))
__init_array_end = .;
. = ALIGN(0x4);
KEEP (*crtbegin.o(.ctors))
KEEP (*(EXCLUDE_FILE (*crtend.o) .ctors))
KEEP (*(SORT(.ctors.*)))
KEEP (*crtend.o(.ctors))
. = ALIGN(4);
KEEP(*(.fini))
. = ALIGN(4);
__fini_array_start = .;
KEEP (*(.fini_array))
KEEP (*(SORT(.fini_array.*)))
__fini_array_end = .;
KEEP (*crtbegin.o(.dtors))
KEEP (*(EXCLUDE_FILE (*crtend.o) .dtors))
KEEP (*(SORT(.dtors.*)))
KEEP (*crtend.o(.dtors))
. = ALIGN(4);
_efixed = .; /* End of text section */
} > rom
/* .ARM.exidx is sorted, so has to go in its own output section. */
PROVIDE_HIDDEN (__exidx_start = .);
.ARM.exidx :
{
*(.ARM.exidx* .gnu.linkonce.armexidx.*)
} > rom
PROVIDE_HIDDEN (__exidx_end = .);
. = ALIGN(4);
_etext = .;
.relocate : AT (_etext)
{
. = ALIGN(4);
_srelocate = .;
*(.ramfunc .ramfunc.*);
*(.data .data.*);
. = ALIGN(4);
_erelocate = .;
} > ram
/* .bss and stack sections removed */
. = ALIGN(4);
_end = . ;
}
Instead of having one RAM variable type foo = value;, simply make one variable const type foo = value; and ensure it is allocated in ROM (should be the case if the variable has static storage duration). Then manually copy it to RAM as needed. This way the value is only stored once in ROM; initializers of ROM variables are not stored separately.
Then you won't be wasting any memory and you won't have to worry about somehow searching through .rodata for the initializer value, which would be rather questionable practice.
I am currently trying to reserve a sector of the flash memory in the linker file, to save some data to it (using the driverlib API). I first flash the script writing to the specific memory addresses, then I run my application which reads the saved data.
Unfortunately whenever I flash, the data is lost. Therefore I am trying to change the linker file and reserve some space but I am not sure if I am doing it correctly. I will appreciate any help or hints.
MEMORY
{
/* Flash Size 128 KB minus the CCA area below (88 bytes) */
/* OLD: FLASH (RX) : ORIGIN = 0x00000000, LENGTH = 0x0001FFA8 */
FLASH (RX) : ORIGIN = 0x00000000, LENGTH = 0x0001FF88
/*
* Custom reserved memory space with size of 32 bytes
*/
CNVM (RX) : ORIGIN = 0x0001FF88, LENGTH = 32
/*
* Customer Configuration Area and Bootloader Backdoor configuration
* in flash, up to 88 bytes
*/
FLASH_CCFG (RX) : ORIGIN = 0x0001FFA8, LENGTH = 88
/* RAM Size 20KB */
SRAM (RWX) : ORIGIN = 0x20000000, LENGTH = 0x00005000
/* Application can use GPRAM region as RAM if cache is disabled in CCFG */
GPRAM (RWX) : ORIGIN = 0x11000000, LENGTH = 0x00002000
}
/*. Highest address of the stack. Used in startup file .*/
_estack = ORIGIN(SRAM) + LENGTH(SRAM); /* End of SRAM */
/*. Generate a link error if heap and stack don’t fit into RAM .*/
_Min_Heap_Size = 0;
_Min_Stack_Size = 0x100;
SECTIONS
{
.text :
{
_text = .;
KEEP(*(.vectors))
*(.text*)
*(.rodata*)
_etext = .;
} > FLASH = 0
.text:
{
*(.rodata*)
} > CNVM
.data :
{
_data = .;
*(vtable)
*(.data*)
_edata = .;
} > SRAM AT > FLASH
.ARM.exidx :
{
*(.ARM.exidx*)
} > FLASH
.bss :
{
_bss = .;
*(.bss*)
*(COMMON)
_ebss = .;
} > SRAM
.ccfg :
{
KEEP(*(.ccfg))
} > FLASH_CCFG
/* User_heap_stack section, used to check that there is enough RAM left */
._user_heap_stack :
{
. = ALIGN(4);
. = . + _Min_Heap_Size;
. = . + _Min_Stack_Size;
. = ALIGN(4);
} > SRAM
.gpram :
{
} > GPRAM
}
Using the linker approach didn't provide the desired result in my case. What I ended up doing instead is editing the generated binary file from my code before flashing the sensortag.
Using the hexdump command on linux as follows hexdump generated_binary_file.bin one can notice that each line includes the start memory address (for a certain range of addresses) followed by the data written to this range.
And so using a small python script one can change the values in a certain line and generate its own modified binary file that will be later flashed to the sensortag. The memory address content can be read with a certain function that you include in your initial code (before bin generation & editing) such memcpy() for example.
I have an embedded system that I am designing using a GNU toolchain. One of the requirements is that it needs to calculate the checksum of the executable code (ROM) at runtime, and compare it to a known value. Depending on weather the calculated value is equal to the known value it will throw an error or not. I need to place the known value in flash memory( where my executable code is stored) in a way that won't change the executable code. AKA I cannot write the value to the flash in my executable code.
I know there are tools that can modify output files to place a checksum in a known address, but for IT reasons external tools are not an option. I decided to use the SHORT() command in the linker and just edit the linker to place the known checksum in a known address at write time. It is not working, and I do not know why.
Relevent Portions of the Linker Script I have:
MEMORY {
m_interrupts (RX) : ORIGIN = 0x00000000, LENGTH = 0x00000400
m_flash_config (RX) : ORIGIN = 0x00000400, LENGTH = 0x00000010
m_interrupts_ram (RW) : ORIGIN = 0x1FFF0000, LENGTH = 0x00000400
m_text (RX) : ORIGIN = 0x00000410, LENGTH = 0x000FFBE0
m_data (RX) : ORIGIN = 0x1FFF0400, LENGTH = 0x0000FC00
m_data_2 (RW) : ORIGIN = 0x20000000, LENGTH = 0x00030000
}
SECTIONS
{
.text :
{
. = ALIGN(4);
*(.fill)
*(.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);
} > m_text
.... More similar sections
....down at the bottom right before stack/heap definition
__ChecksumStart = 0xFFFE0;
.checksum : AT(__ChecksumStart)
{
. = ALIGN (0x4);
SHORT(0xABCD)
} > m_text
__ChecksumSize = SIZEOF(.checksum);
.heap :
{
. = ALIGN(8);
__end__ = .;
PROVIDE(end = .);
__HeapBase = .;
. += HEAP_SIZE;
__HeapLimit = .;
} > m_data_2
.stack :
{
. = ALIGN(8);
. += STACK_SIZE;
} > m_data_2
__StackTop = ORIGIN(m_data_2) + LENGTH(m_data_2);
__StackLimit = __StackTop - STACK_SIZE;
PROVIDE(__stack = __StackTop);
.ARM.attributes 0 : { *(.ARM.attributes) }
} //end of SECTIONS block here
I should be able to look at location 0xFFFE0 in my executable code and see 0xABCD. I do not. I see 0xFFFFFFFF the default value. What do I need to change to make this work? I have looked at this tutorial to get this far
I have to place array at specific address in memory. I'm using GCC.
I declare variable like this:
uint8_t __attribute__((section (".mySection"))) buffer[1234];
And in linker script I've got:
MEMORY
{
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 1024K
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 145K
MYSEC (x) : ORIGIN = 0x20025000, LENGTH = 155K
}
and later:
.mySection :
{
*(.mySection);
} > MYSEC
It's of course code for embedded system (ARM). Normally my program takes 22 KB, with this modification it takes 384 MB (!).
I don't understand why. If I remove __attribute__ it takes 22 KB again.
What am I missing?
Code used:
#inculde (...)
uint8_t __attribute__((section (".mySection"))) buffer = 5;
int main(void){
buffer = 10;
}
Full linker script (default, not written by me, parts are shortened:
/* Entry Point */
ENTRY(Reset_Handler)
/* Highest address of the user mode stack */
_estack = 0x20050000; /* end of RAM */
/* Generate a link error if heap and stack don't fit into RAM */
_Min_Heap_Size = 0x200; /* required amount of heap */
_Min_Stack_Size = 0x400; /* required amount of stack */
/* Specify the memory areas */
MEMORY
{
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 1024K
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 145K
MYSEC (x) : ORIGIN = 0x20025000, LENGTH = 155K
}
/* Define output sections */
SECTIONS
{
/* The startup code goes first into FLASH */
.isr_vector :
{
(...)
} >FLASH
/* The program code and other data goes into FLASH */
.text :
{
(...)
} >FLASH
/* Constant data goes into FLASH */
.rodata :
{
(...)
} >FLASH
.ARM.extab : { *(.ARM.extab* .gnu.linkonce.armextab.*) } >FLASH
.ARM : {
(...)
} >FLASH
.preinit_array :
{
(...)
} >FLASH
.init_array :
{
(...)
} >FLASH
.fini_array :
{
(...)
} >FLASH
/* used by the startup to initialize data */
_sidata = LOADADDR(.data);
/* Initialized data sections goes into RAM, load LMA copy after code */
.data :
{
(...)
} >RAM AT> FLASH
.mySection :
{
*(.mySection);
} > MYSEC
/* Uninitialized data section */
. = ALIGN(4);
.bss :
{
(...)
} >RAM
/* User_heap_stack section, used to check that there is enough RAM left */
._user_heap_stack :
{
(...)
} >RAM
/* Remove information from the standard libraries */
/DISCARD/ :
{
(...)
}
.ARM.attributes 0 : { *(.ARM.attributes) }
}
I assume your output file is a pure binary format, not an ELF so you don't have ELF bootloader. In that case, placing initialized data at high address obviously will create a big output file. This is because in the binary format you don't have any mechanism to provide specific address, so the file is mapped 1:1 into memory. It means the whole address space up to your custom initialized variable needs to be included in the output file.
This is the same situation as with .data section and this is why the .data section is explicitly copied from Flash into RAM area at the startup.
p.s. You can find my article helpful (this issue is described there).