Joe Pep wrote:
> Hello.
>
> I'm using the Eclipse/gcc/yagarto toolchain on the AT91SAM7X256-EK
> Evaluation Board, with the provided httpd project (with httpserv.c as
> the main source file).

Provided from where? Is it code included in the Yagarto pacakge?

> I want to tell the compiler to place a flash
> write function in ram.
>
> I've defined the RAMFUNC keyword with:
>
> #define RAMFUNC _attribute_ ((long_call, section (".ramsection")))
>
> Now I need to modify my linker map file with the following code:
> (From : http://www.embeddedrelated.com/groups/AT91SAM/show/1358.php )
>

The method you have used should work. Just add RAMFUNC to the function
which will be replaced by the attribute. The modifications in the
linker-script looks ok.

>
> I cannot determine which linker map file is being used. I'm not even
> sure if the .map file in the httpd project folder is being used or one
> of the .ld files in /NutOS/nut/arch/arm/ldscripts folder. The .map file
> syntax doesn't resemble that of the above code as much as does the
> syntax of the .ld files.

Can you locate the -T option in the/one of the makefile(s)?


Martin Thomas

Martin Thomas wrote:
> Joe Pep wrote:
>> Hello.
>>
>> I'm using the Eclipse/gcc/yagarto toolchain on the AT91SAM7X256-EK
>> Evaluation Board, with the provided httpd project (with httpserv.c as
>> the main source file).
>
> Provided from where? Is it code included in the Yagarto pacakge?
>
>> I want to tell the compiler to place a flash
>> write function in ram.
>>
>> I've defined the RAMFUNC keyword with:
>>
>> #define RAMFUNC _attribute_ ((long_call, section (".ramsection")))
>>
>> Now I need to modify my linker map file with the following code:
>> (From : http://www.embeddedrelated.com/groups/AT91SAM/show/1358.php )
>>
>
> The method you have used should work. Just add RAMFUNC to the function
> which will be replaced by the attribute. The modifications in the
> linker-script looks ok.
>
>>
>> I cannot determine which linker map file is being used. I'm not even
>> sure if the .map file in the httpd project folder is being used or one
>> of the .ld files in /NutOS/nut/arch/arm/ldscripts folder. The .map file
>> syntax doesn't resemble that of the above code as much as does the
>> syntax of the .ld files.
>
> Can you locate the -T option in the/one of the makefile(s)?
>
>
> Martin Thomas


Hello, Martin,

Thanks much for the guidance.
The httpd project, along with a few others, was supplied with the
AT91SAM7X256-EK evaluation kit, and I believe put together by Atmel.
I also should have informed in my first post that this project
is built on the NutOS platform. Perhaps this changes some things ??

I found the -T option in the console output and my linker map file is
/nut/arch/arm/ldscripts/at91sam7x256_rom.ld.

I added the DATA code as quoted above and added the following definition
line
  to the MEMORY section, as the compiler immediately complained about
DATA
  not being defined :
  DATA (rw)  : org = 0x00200000, len = 64k

I also removed the spurious (I think) characters =09 after the
close of the first comment.  ---  /* added by mthomas */=09

The next compiler complaint is the following:
c:\sam studio
0.2\yagarto\bin\..\lib\gcc\arm-elf\4.1.1\..\..\..\..\arm-elf\
  bin\ld.exe:../.././nut/arch/arm/ldscripts/at91sam7x256_rom.ld:
  97: syntax error
  collect2: ld returned 1 exit status
The linker map code being referred to here is:
  . =3D ALIGN(4);

I found nearly identical code elsewhere that omitted the 3D characters.
I tried this, and I get build completion, but the app crashes or never
starts,
which initially sounds like a symptom of the flashwrite function running
from flash, but I've commented the call to the function.

I'm defining RAMFUNC with this, in the same .c file that defines
  the flashwrite function :

#define RAMFUNC _attribute_ ((long_call, section (".ramsection")))

I've also tried this:
#define RAMFUNC _attribute_ ((long_call, section (".fastrun")))
  and changed the .ramsection word to fastrun in the map file.
Same crash result.


The function call is like this, but the app crashes even when I
  comment the call.
flash_return_code = FlashWrite (int flash_offset, const void *buf, int
len);
{
...
}

I've repeatedly deleted the added linker map code, and the app runs
flawlessly every time.

Puzzled ...

Joe Pep wrote:
> Martin Thomas wrote:
>> Joe Pep wrote:
>>> Hello.
>>>
>>> I'm using the Eclipse/gcc/yagarto toolchain on the AT91SAM7X256-EK
>>> Evaluation Board, with the provided httpd project (with httpserv.c as
>>> the main source file).
>>
>> Provided from where? Is it code included in the Yagarto pacakge?
>>
>>> I want to tell the compiler to place a flash
>>> write function in ram.
>>>
>>> I've defined the RAMFUNC keyword with:
>>>
>>> #define RAMFUNC _attribute_ ((long_call, section (".ramsection")))
>>>
>>> Now I need to modify my linker map file with the following code:
>>> (From : http://www.embeddedrelated.com/groups/AT91SAM/show/1358.php )
>>>
>>
>> The method you have used should work. Just add RAMFUNC to the function
>> which will be replaced by the attribute. The modifications in the
>> linker-script looks ok.
>>
>>>
>>> I cannot determine which linker map file is being used. I'm not even
>>> sure if the .map file in the httpd project folder is being used or one
>>> of the .ld files in /NutOS/nut/arch/arm/ldscripts folder. The .map file
>>> syntax doesn't resemble that of the above code as much as does the
>>> syntax of the .ld files.
>>
>> Can you locate the -T option in the/one of the makefile(s)?
>>
>>
>> Martin Thomas
>
>
> Hello, Martin,
>
> Thanks much for the guidance.
> The httpd project, along with a few others, was supplied with the
> AT91SAM7X256-EK evaluation kit, and I believe put together by Atmel.
> I also should have informed in my first post that this project
> is built on the NutOS platform. Perhaps this changes some things ??

Hmm, I do not have the SAM7X-EK so I do not have the "supplied code".
Can it be downloaded from atmel.com or at91.com? Is it a unmodified
nutos-code available from the nutos sf.net-area? Difficult to help
without looking into the code.

> I found the -T option in the console output and my linker map file is
> /nut/arch/arm/ldscripts/at91sam7x256_rom.ld.
>
> I added the DATA code as quoted above and added the following definition
> line
>   to the MEMORY section, as the compiler immediately complained about
> DATA
>   not being defined :
>   DATA (rw)  : org = 0x00200000, len = 64k

Maybe another label is used. Sometimes labels as RAM or IRAM get used.
Again difficult to help without knowing the complete linker-script.

> I also removed the spurious (I think) characters =09 after the
> close of the first comment.  ---  /* added by mthomas */=09
>
> The next compiler complaint is the following:
> c:\sam studio
> 0.2\yagarto\bin\..\lib\gcc\arm-elf\4.1.1\..\..\..\..\arm-elf\
>   bin\ld.exe:../.././nut/arch/arm/ldscripts/at91sam7x256_rom.ld:
>   97: syntax error
>   collect2: ld returned 1 exit status
> The linker map code being referred to here is:
>   . =3D ALIGN(4);
> I found nearly identical code elsewhere that omitted the 3D characters.
> I tried this, and I get build completion,

Although the lines cited in the forum seem to be from me I have never
user something like /=... It seems that /=09 and /=03 have been inserted
by the forum-software from where you have copied the lines.

> but the app crashes or never
> starts,
> which initially sounds like a symptom of the flashwrite function running
> from flash, but I've commented the call to the function.
>
> I'm defining RAMFUNC with this, in the same .c file that defines
>   the flashwrite function :
>
> #define RAMFUNC _attribute_ ((long_call, section (".ramsection")))
>
> I've also tried this:
> #define RAMFUNC _attribute_ ((long_call, section (".fastrun")))
>   and changed the .ramsection word to fastrun in the map file.
> Same crash result.

The C-section name in the attribute must be the same name as the one
used in the linker-script (in the .data-linker-section). It does not
matter which name you choose but it must be the same. Or the linker can
not assign memory-addresses.

The you declare the function FlashWrite with the function-attributes (by
using the macro)?

> The function call is like this, but the app crashes even when I
>   comment the call.
> flash_return_code = FlashWrite (int flash_offset, const void *buf, int
> len);
> {
> ...
> }
>
> I've repeatedly deleted the added linker map code, and the app runs
> flawlessly every time.

Review the map-file to verify that the function is located in RAM
address-space. Check if the flash-function calls and other functions.
Depending on at which stage of the FlashWrite function they are called
they also have to be located in RAM. It can be a little difficult to
move functions from the libgcc or libc into RAM but it is possible. It
may be easier to use own replacements for runtime-functions as "inlines"
or macros or functions in "RAM".

> Puzzled ...
First of all create a map-file and a dissassembly to verify that
FlashWrite is located in RAM (VMA in the AT91 ram-memory address-range)
when called. Than check if other functions are called from inside
FlashWrite.

Martin Thomas

Martin Thomas wrote:
> Joe Pep wrote:
>> Martin Thomas wrote:
>>> Joe Pep wrote:
>>>> Hello.
>>>>
>>>> I'm using the Eclipse/gcc/yagarto toolchain on the AT91SAM7X256-EK
>>>> Evaluation Board, with the provided httpd project (with httpserv.c as
>>>> the main source file).
>>>
>>> Provided from where? Is it code included in the Yagarto pacakge?
>>>
>>>> I want to tell the compiler to place a flash
>>>> write function in ram.
>>>>
>>>> I've defined the RAMFUNC keyword with:
>>>>
>>>> #define RAMFUNC _attribute_ ((long_call, section (".ramsection")))
>>>>
>>>> Now I need to modify my linker map file with the following code:
>>>> (From : http://www.embeddedrelated.com/groups/AT91SAM/show/1358.php )
>>>>
>>>
>>> The method you have used should work. Just add RAMFUNC to the function
>>> which will be replaced by the attribute. The modifications in the
>>> linker-script looks ok.
>>>
>>>>
>>>> I cannot determine which linker map file is being used. I'm not even
>>>> sure if the .map file in the httpd project folder is being used or one
>>>> of the .ld files in /NutOS/nut/arch/arm/ldscripts folder. The .map file
>>>> syntax doesn't resemble that of the above code as much as does the
>>>> syntax of the .ld files.
>>>
>>> Can you locate the -T option in the/one of the makefile(s)?
>>>
>>>
>>> Martin Thomas
>>
>>
>> Hello, Martin,
>>
>> Thanks much for the guidance.
>> The httpd project, along with a few others, was supplied with the
>> AT91SAM7X256-EK evaluation kit, and I believe put together by Atmel.
>> I also should have informed in my first post that this project
>> is built on the NutOS platform. Perhaps this changes some things ??
>
> Hmm, I do not have the SAM7X-EK so I do not have the "supplied code".
> Can it be downloaded from atmel.com or at91.com? Is it a unmodified
> nutos-code available from the nutos sf.net-area? Difficult to help
> without looking into the code.
>
>> I found the -T option in the console output and my linker map file is
>> /nut/arch/arm/ldscripts/at91sam7x256_rom.ld.
>>
>> I added the DATA code as quoted above and added the following definition
>> line
>>   to the MEMORY section, as the compiler immediately complained about
>> DATA
>>   not being defined :
>>   DATA (rw)  : org = 0x00200000, len = 64k
>
> Maybe another label is used. Sometimes labels as RAM or IRAM get used.
> Again difficult to help without knowing the complete linker-script.
>
>> I also removed the spurious (I think) characters =09 after the
>> close of the first comment.  ---  /* added by mthomas */=09
>>
>> The next compiler complaint is the following:
>> c:\sam studio
>> 0.2\yagarto\bin\..\lib\gcc\arm-elf\4.1.1\..\..\..\..\arm-elf\
>>   bin\ld.exe:../.././nut/arch/arm/ldscripts/at91sam7x256_rom.ld:
>>   97: syntax error
>>   collect2: ld returned 1 exit status
>> The linker map code being referred to here is:
>>   . =3D ALIGN(4);
>> I found nearly identical code elsewhere that omitted the 3D characters.
>> I tried this, and I get build completion,
>
> Although the lines cited in the forum seem to be from me I have never
> user something like /=... It seems that /=09 and /=03 have been inserted
> by the forum-software from where you have copied the lines.
>
>> but the app crashes or never
>> starts,
>> which initially sounds like a symptom of the flashwrite function running
>> from flash, but I've commented the call to the function.
>>
>> I'm defining RAMFUNC with this, in the same .c file that defines
>>   the flashwrite function :
>>
>> #define RAMFUNC _attribute_ ((long_call, section (".ramsection")))
>>
>> I've also tried this:
>> #define RAMFUNC _attribute_ ((long_call, section (".fastrun")))
>>   and changed the .ramsection word to fastrun in the map file.
>> Same crash result.
>
> The C-section name in the attribute must be the same name as the one
> used in the linker-script (in the .data-linker-section). It does not
> matter which name you choose but it must be the same. Or the linker can
> not assign memory-addresses.
>
> The you declare the function FlashWrite with the function-attributes (by
> using the macro)?
>
>> The function call is like this, but the app crashes even when I
>>   comment the call.
>> flash_return_code = FlashWrite (int flash_offset, const void *buf, int
>> len);
>> {
>> ...
>> }
>>
>> I've repeatedly deleted the added linker map code, and the app runs
>> flawlessly every time.
>
> Review the map-file to verify that the function is located in RAM
> address-space. Check if the flash-function calls and other functions.
> Depending on at which stage of the FlashWrite function they are called
> they also have to be located in RAM. It can be a little difficult to
> move functions from the libgcc or libc into RAM but it is possible. It
> may be easier to use own replacements for runtime-functions as "inlines"
> or macros or functions in "RAM".
>
>> Puzzled ...
> First of all create a map-file and a dissassembly to verify that
> FlashWrite is located in RAM (VMA in the AT91 ram-memory address-range)
> when called. Than check if other functions are called from inside
> FlashWrite.
>
> Martin Thomas

Hello, Martin.

Many thanks again.

My app now compiles and runs up to the point of calling the flashwrite
function.
Apparently it's still not being run from RAM. I've placed the entire
routine at the bottom along with the entire linker map file. The
original .data section is this (in file at917sam7x256_rom.ld linker
map):

 .data : AT (__etext)
  {
    PROVIDE (__data_start = .);
    *(.data)
    . = ALIGN(4);
    *(.ramfunc)
    _edata = .;
    PROVIDE (__data_end = .);
  } > ram


I've tried various combinations of the above section statements and
those of the snippet provided by Ewout at
http://www.embeddedrelated.com/groups/AT91SAM/show/1358.php .

All variations run fine if I comment and don't call the flashwrite
routine.
The minute I uncomment it, app crashes.


The following definition is in the linker map file:

MEMORY
{
  rom(rx) : org = 0x00000000, len = 240k
  ram(rw) : org = 0x00200000, len = 64k
}

I don't know what to make of the 0x00200000, as this translates to
2,097,152.
The only way this makes sense is that it represents bits, not bytes.
Is this correct ?

Also, there are no other functions called from within the flashwrite
function.
There are however, many constants defined in .h files. Is it possible
these
need to be placed in RAM somehow?   If so, how would this be done?

How would I create a map file and disassembly to verify the functions
presence in RAM ?

Thanks,
Joe



/*__________________________________________________________________*/
/* Flashwrite function :


int FlashWrite(int i, const void *b, int m) RAMFUNC;

RAMFUNC int FlashWrite (int flash_offset, const void *buf, int len)
{
    volatile unsigned int enabled_ints;

    unsigned int *b = (unsigned int *)buf;

    int rem;
    unsigned int start;
    unsigned int *f;

    int page_offset;
    int start_of_page;
    int page_size;
    int num_pages;
    int page_num;
    int page_copy_len;

    if ((unsigned int)b & 3) {
        return -1;      /* Source buffer must be 32-bit aligned */
       }

    /* Round the length up to a multiple of 32-bit words */
    rem = (len + 3) & ~3;

    /* Set the Flash Microsecond Cycle Number field in the Flash Mode
Register
     * (the number of MCKs in 1.5us) */
    /* If this is not set, the flash write may succeed, but subsequent
accesses
     * will generate memory faults or bad data. */
    AT91C_BASE_MC->MC_FMR |= ((MCK * 15 / 10000000) + 1) << 16;

#ifdef USE_CHIPID_FOR_FLASH_DESC
    {
        unsigned int nvpsiz = ((*AT91C_DBGU_CIDR) >> 8) & 0xf;
        page_size = flash_desc_table[nvpsiz].page_size;
        num_pages = flash_desc_table[nvpsiz].num_pages;
    }
#else
    page_size = AT91C_IFLASH_PAGE_SIZE;
    num_pages = AT91C_IFLASH_NB_OF_PAGES;
#endif

    if ((flash_offset + rem) > (page_size * num_pages)) {
        return -4;     /* Would write past the end of flash */
    }

    // start = START_OF_FLASH + flash_offset;   // yyyy JCP 09/03/07

    /* Want to write some distance from end of flash */
    start = AT91C_IFLASH_SIZE  - flash_offset;   // yyyy JCP 09/03/07

    f = (unsigned int *)start;


    /* Flash page sizes are a power of 2 */
    page_offset = flash_offset & (page_size - 1);
    start_of_page = start - page_offset;
    page_num = flash_offset / page_size;
    page_copy_len = page_size;

    if (page_offset > 0) {
        unsigned int *p = (unsigned int *)start_of_page;
        int copy_words = page_offset >> 2;
        while (copy_words--) {
            unsigned int x = *p;
            *p++ = x;
        }
        page_copy_len -= page_offset;
    }

    while (rem > 0) {
        if (page_copy_len >= rem) {
            page_copy_len = rem;
        }

        {   /* Copy NVM data into flash page buffer */
            int copy_words = page_copy_len >> 2;
            while (copy_words--) {
                *f++ = *b++;
            }
        }


        /* Disable all interrupts while flash write command is
executing.
         * Interrupt handlers may be in flash which cannot be read
during
         * flash write.
         * The interrupts will be re-enabled when the flash write
completes. */
        enabled_ints = AT91C_BASE_AIC->AIC_IMR;
        AT91C_BASE_AIC->AIC_IDCR = 0xffffffff;

/* return 678;   Gets this far without crash */

        /* Issue flash write command for the current page */
        AT91C_BASE_MC->MC_FCR = (0x5a << 24) |         /* Key */
                                AT91C_MC_FCMD_START_PROG |
                                (page_num << 8);

return 678;  /* yyyy -- code never gets here 09/03/07--probably running
from
                flash and not RAM.
                The above flash write command causes the crash.
                */



        /* Wait for flash write command to complete */
        while (0 == (AT91C_BASE_MC->MC_FSR & AT91C_MC_FRDY));

        /* Re-enable interrupts */
        AT91C_BASE_AIC->AIC_IECR = enabled_ints;

        if (AT91C_BASE_MC->MC_FSR & (AT91C_MC_LOCKE | AT91C_MC_PROGE)) {
            return -2;    /* Error - region was locked or bad command */
        }

        page_num++;
        rem -= page_copy_len;
        page_copy_len = page_size;    /* Copy a full page for the
remaining pages */
    }

    {   /* Verify the flash contents against the buffer */
        unsigned char *b = (unsigned char *)buf;
        unsigned char *f = (unsigned char *)start;
        while (len--) {
            if (*b++ != *f++) {
                return -3;    /* Something didn't match */
            }
        }
    }

    return 0;   /* Flash write successful */
}




/*__________________________________________________________________*/
/* Linker map file : at91samx256_rom.ld   as it's being used in my app :

ENTRY(_start)
STARTUP(crtat91sam7x256_rom.o)
SEARCH_DIR(.)

/* Last 16k flash is used to save config. */
MEMORY
{
  rom(rx) : org = 0x00000000, len = 240k
  ram(rw) : org = 0x00200000, len = 64k
}

SECTIONS
{
  .text :
  {
    *(.vectors);
    . = ALIGN(4);
    *(.init0);
    . = ALIGN(4);
    *(.init1);
    . = ALIGN(4);
    *(.init2);
    . = ALIGN(4);
    *(.init3);
    . = ALIGN(4);
    *(.init4);
    . = ALIGN(4);
    *(.init5);
    . = ALIGN(4);
    *(.text);
    . = ALIGN(4);
    *(.rodata*);
    . = ALIGN(4);
    *(.glue_7t);
    . = ALIGN(4);
    *(.glue_7);
  } > rom

  . = ALIGN(4);

  _etext = .;
  PROVIDE (__etext = .);

/* Original .data section was here --------------------*/


/* Altered .data section ----------------------------- */
 .data : AT (__etext)
  {
    _data = . ;
    data = .;
    PROVIDE (__data_start = .);
    KEEP(*(.vectram))
    *(.data)
    SORT(CONSTRUCTORS)
    . = ALIGN(4);
    *(.ramfunc)
    _edata = .;
    PROVIDE (__data_end = .);
  } > ram

  . = ALIGN(4);





  .bss :
  {
    PROVIDE (__bss_start = .);
    *(.bss)
    *(COMMON)
    . = ALIGN(4);
    PROVIDE (__bss_end = .);
    . += 0x400;
    PROVIDE (__exp_stack = .);
    . += 0x400;
    PROVIDE (__stack = .);
    PROVIDE (__heap_start = .);
  } > ram

  .stab 0 (NOLOAD) :
  {
    [ .stab ]
  }
  .stabstr 0 (NOLOAD) :
  {
    [ .stabstr ]
  }
}

Joe Pep wrote:
>...
> My app now compiles and runs up to the point of calling the flashwrite
> function.
> Apparently it's still not being run from RAM.
You can check this yourself, create a map-file, symbol-file and
disassembly and read them.

>...
> I've placed the entire
> routine at the bottom along with the entire linker map file.
You have given a linker-script not a map-file.

>...
> The following definition is in the linker map file:
You mean linker script. A map-file (at least what I know as map-file) is
created by the linker and shows which addresses have been assigned.

>...
> MEMORY
> {
>   rom(rx) : org = 0x00000000, len = 240k
>   ram(rw) : org = 0x00200000, len = 64k
> }
>
> I don't know what to make of the 0x00200000, as this translates to
> 2,097,152.
> The only way this makes sense is that it represents bits, not bytes.
> Is this correct ?
I do not realy understand. The entires looks o.k. to me for AT91SAM7. I
usualy use ORIGIN instead of org and LENGTH instead of len but this
should not make a difference.

>...
> Also, there are no other functions called from within the flashwrite
> function.
Are you sure? Although you do not call any "user functions" functions.
Functions from the libgcc may be used "in the background". As already
suggested let the linker create a map-file (-Map) and create a
disassembly from the elf-file with objdump.

>...
> There are however, many constants defined in .h files. Is it possible
> these need to be placed in RAM somehow?   If so, how would this be done?
Not if they are defined (#define). Than the preprocessor will just
replace them.

>...
> How would I create a map file and disassembly to verify the functions
> presence in RAM ?
map-file: -Map option to the linker. If you call the linker from the
compiler frontend (arm-*-gcc) pass the -Map option with -Wl
disassembly: arm-*-objdump
The Makefiles coming with my ARM examples may serve as templates.

>...

Martin Thomas

I think about your bootcode maybe not copies _etext from ROM to RAM. My
bootloader copies _etext part from ROM into _edata part in RAM section.
That must be proceed before any initialized variable or function used in
RAM, especially in boot time. System maybe crash if it was forgotten.
You need to inspect your bootcode, that maybe aswers for your all
question.

regards