Writing the default const values to the flash information block

lpcware · ‎06-15-2016

Content originally posted in LPCWare by abhilash.bidari on Thu Mar 15 06:03:11 MST 2012
Hello.

Controller: LPC1227

I want to write some default values to the flash information block

I have modified the linker script as given below.
Memory map properly.
But once i download the code iam not able to see the default values in the flash information block

[FONT=Courier New]debug_mem.ld[/FONT]
[FONT=Courier New][/FONT] 
[FONT=Courier New]MEMORY
{
  /* Define each memory region */
  MFlash128 (rx) : ORIGIN = 0x0, LENGTH = 0x20000 /* 128k */
  RamLoc8 (rwx) : ORIGIN = 0x10000000, LENGTH = 0x2000 /* 8k */
  InfoFlash(rx) :  ORIGIN = 0x00040200, LENGTH = 0x200  [/FONT]
[FONT=Courier New]}[/FONT]
[FONT=Courier New][/FONT] 
[FONT=Courier New]debug.ld[/FONT]
[FONT=Courier New][/FONT] 
[FONT=Courier New].rodata :
{ 
   PROVIDE(__init_start = 0x00040200);[/FONT]
[FONT=Courier New]   KEEP(*(.infodata*));
   *(.rodata*)[/FONT]
[FONT=Courier New]   PROVIDE(__init_end = 0x00040400);
} > InfoFlash[/FONT]
[FONT=Courier New][/FONT] 
[FONT=Courier New][/FONT] 
[FONT=Courier New]source code[/FONT]
[FONT=Courier New][/FONT] 
[FONT=Courier New][/FONT] 
[FONT=Courier New]__attribute__ ((section(".eeprom"))) const chardataval[4]={ 1,1,1,1};[/FONT]
[IMG]https://mail.google.com/mail/images/cleardot.gif[/IMG]

please tell me what is the problem

in map file it is coming as

.rodata 0x00040200 0xa
*(.infodata*)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by abhilash.bidari on Mon Mar 19 00:32:16 MST 2012
I also tried to split the code memory itself, as you shown "Dataflash".

For me it is compiling and map file is generating properly. But when i download and start to run the code, control is going to "hardfault handler" function insted "main" function.

What is the problem..

whether i shold not do like below.
__attribute__ ((__section__(".flash.data"))) const char dataval[4] = {1,1,1,1};
While declaring the i shold not define the variables. If not then when i should define the variables.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Rob65 on Sat Mar 17 01:34:51 MST 2012

Quote: abhilash.bidari

in map file it is coming as

.rodata 0x00040200 0xa
*(.infodata*)

Which does not surprise me at all.
If you write:

MEMORY
{
  /* Define each memory region */
  MFlash128 (rx) : ORIGIN = 0x0, LENGTH = 0x20000 /* 128k */
  RamLoc8 (rwx) : ORIGIN = 0x10000000, LENGTH = 0x2000 /* 8k */
  [B][COLOR=Red]InfoFlash(rx)[/COLOR][/B] :  ORIGIN = 0x00040200, LENGTH = 0x200  
}
[B][COLOR=Red].rodata[/COLOR][/B] :
{ 
   PROVIDE(__init_start = 0x00040200);
   KEEP(*(.infodata*));
   *(.rodata*)
   PROVIDE(__init_end = 0x00040400);
} > [B][COLOR=Red]InfoFlash[/COLOR][/B]

then where else would you think this would go ?

You named your section .rodata which is just an arbitrary name. But this name is kind of 'reserved' in that this is the default name for read only data sections used by some compilers to mark read only data.
But still - it seems to be working like you wanted it to. Just have a look at the .map file.

To make this generally usable for others as well I defined a separate memory section called DataFlash and a memory section .flashdata:

MEMORY
{
  /* Define each memory region */
  MFlash128 (rx) : ORIGIN = 0x0, LENGTH = 0x1f000 /* 128k */
  [B][COLOR=Red]DataFlash (rw) : ORIGIN = 0x1f000, LENGTH = 0x1000[/COLOR][/B]
  RamLoc16 (rwx) : ORIGIN = 0x10000000, LENGTH = 0x4000 /* 16k */
  RamAHB16 (rwx) : ORIGIN = 0x2007c000, LENGTH = 0x4000 /* 16k */

}

SECTIONS
{

...
    .flashdata : ALIGN(4)
    {
        KEEP(*(.flash.data*))
        . = ALIGN(4);
    } > [B][COLOR=Red]DataFlash[/COLOR][/B]
...
}

And in my C-code:

__attribute__ ((__section__(".flash.data"))) const char dataval[4];

If I compile and look in the .map file this ends up as:

.flashdata      0x0001f000        0x4
 *(.flash.data*)
 .flash.data    0x0001f000        0x4 ./src/main.o
                0x0001f000                dataval
                0x0001f004                . = ALIGN (0x4)

I think you'll grasp the way of doing this but I will still explain a bit just for others as well:

The memory region DataFlash is the top part of my Flash memory (you might want to align this to a complete flash block) - it defines the physical memory and the addresses.

The [B][FONT=Courier New].dataflash { ... } > DataFlash[/FONT][/B] just tells that there is an overall section called .dataflash in which everything in the '...' is collected and this section is mapped in the (physical) memory region called DataFlash.

The [B][FONT=Courier New]*(.flash.data*)[/FONT][/B] is the way to specify that all sections that are named .flash.data are collected. With the [B][FONT=Courier New]KEEP(...)[/FONT][/B] around this we specify that whatever happens, these sections should always be loaded.

In the .map file we see that the .flashdata section is 4 bytes long and that it contains the .flash.data section.
The extra asterisk in the flash.data.* definition allows us to use multiple names.

Have a look at the example:

__attribute__ ((__section__(".flash.data1"))) const char dataval1[4];
__attribute__ ((__section__(".flash.data2"))) const char dataval2[4];
__attribute__ ((__section__(".flash.data1"))) const char dataval3[7];

.flashdata      0x0001f000       0x10
 *(.flash.data*)
 .flash.data1   0x0001f000        0xc ./src/main.o
                0x0001f000                dataval1
                0x0001f004                dataval3
 .flash.data2   0x0001f00c        0x4 ./src/main.o
                0x0001f00c                dataval2
                0x0001f010                . = ALIGN (0x4)

This results in two different sections .flash.data1 and .flash.data2 that are collected into the .flashdata section (in my DataFlash memory region). Dataval1 and dataval3 are placed in the .flash.data1 section - this is a total of 11 bytes but since I specified the ALIGN(4) on .flashdata each section is aligned at 4 bytes. Dataval2 is placed in section .flash.data2

Please note that the order of placement of these sections is arbitrary (in the order in which the linker sees them) and not alphabetically ordered.

Regards,[INDENT]Rob
[/INDENT]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by abhilash.bidari on Sat Mar 17 00:31:34 MST 2012
Here Iam attaching the zip file contains ld script and map file.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by abhilash.bidari on Sat Mar 17 00:23:52 MST 2012
here iam attaching ld scripts and

lpcware · ‎06-15-2016

Content originally posted in LPCWare by abhilash.bidari on Fri Mar 16 22:46:33 MST 2012
sorry by mistake i have written eeprom

actual code in the source file is as below

__attribute__ ((section(".infodata"))) const chardataval[4]={ 1,1,1,1};
[IMG]https://mail.google.com/mail/images/cleardot.gif[/IMG]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Fri Mar 16 08:22:38 MST 2012
So where is you linker script placing the section ".eeprom" that you are using in your code, as opposed to the placing of the section ".infodata" that you appear to have in your linker script?

If that doesn't solve your problem, then please post your actually map file and full linker script(s).

PS - this might be of use generally...

http://support.code-red-tech.com/CodeRedWiki/PlacingData

Regards,
CodeRedSupport

lpcware · ‎06-15-2016

Content originally posted in LPCWare by abhilash.bidari on Fri Mar 16 02:12:22 MST 2012
Please any one help regarding this,