Reply by Mariano Filippa ●January 7, 20042004-01-07
Thank you for the code !! It is really helpful.

You initialization is pretty much like mine. You are copying from xROM to
xRAM with C. That works excellent.

I also noticed that you got rid of MSL C library. I tried to get rid of it
but when I use a #pragma interrupt, the compiler calls a couple of functions
to save registers. I noticed that you used pure assembly in your ISR. Is
this the reason why you used asm?

I was thinking of writing my ISR in C without the #pragma. Then, I will have
something like:

#define ExitISR asm( rti )

void MyISR(void){
SaveRegisters();
// code goes here
ExitISR;
}

And I will have the following too:

asm void SaveRegisters(void){
// code in assemble for saving registers in stack
// can be copied from MSL C library or make your own
}

When compiled, I will have a RTI followed by an RTS, but it doesn't harm to
have the RTS.
By the way, pretty neat coding. Well done!

Regards,
Mariano ----- Original Message -----
From: "Thomas Kracke" <>
To: <>
Sent: Tuesday, January 06, 2004 7:28 PM
Subject: [motoroladsp] Sections (.bss) , (.rodata) and (.data) ... where and
how to place them? > Hallo Mariano,
>
> I had the same problems with CW a few weeks ago.
> The bad thing is: CW has differences between the
> versions for different controllers. I solved the
> problem with the MPC555 two years ago, but the CW for
> DSP56803 has some differences.
> I attached a complete project, which I run with CW
> Version . Please have a look on file DSP56803.c line
> 284 ff. and the file linker.cmd.
>
> I hope this help you.
>
> =====
>
> mit freundlichen Gruen,
>
> Thomas Kracke
>
> __________________________________
>



Reply by Mariano Filippa ●January 6, 20042004-01-06
Thanks for the prompt reply. This is very helpful. I regret this is not fully explained in the targeting manual... :(
 
I assume that when you define F__ROM_Address , its address points to data (x) memory if its included in a data (x) section . Same goes if it is used within a program (p) section. Please, correct me if I'm wrong:
 
****** if initialized variables are to be placed in data (x) ROM:
 

.app_data : AT( F__x_ROM_Address ) # place them in .x_FLASH, say 0x1000

{

    F_Begin_Data = .;               

    *(.data)                 

    F_End_Data = .;                 

} > .x_RAM                     # declare them to be in .x_RAM, say 0x0000

 

****** if initialized variables are to be placed in program (p) ROM:
 

.app_data : AT ( F__p_ROM_Address) # place them in .p_FLASH, say 0x1000

{

  F_Begin_Data = .;            
  * (.data)                    
  F_End_Data = .;             
} > .p_xRAM_mirror      # Declare them to be in program (p) memory

                        #  at the intended data (x) address (mirror).

                        # The compiler will access data memory anyway,

                        #  no matter if they were declared in program memory

 

However, here's my question: As you said, "...codewarrior doesn't make difference between x-mem and p-mem pointers ...". So, for the second case, I cannot use C to copy variables from pROM to xRAM (the memcpy function). I should use assembly. Is this right? Targeting does not specify how to do it...

 

And last, does Motorola or Metrowerks have another ELF language manual? I'm really confused with:

a) global variables: prepend F or use double underscore? I see them mixed everywhere...

b) I had no idea that >> means "append" to section

Where can I get a good description of the sintax? Targeting isn't doing a good job....

 

Thank you very much for your help. This is starting to work really fine. I must confess that I was going to get a TI dsp. But now, I really want to stick to Motorola MCUs and DSPs. Keep up the good work ! :)

 

Mariano Filippa

m...@umd.umich.edu

 

 
----- Original Message -----
From: Dobsik Lubomir-RC085C
To: Mariano Filippa
Sent: Tuesday, January 06, 2004 9:33 AM
Subject: RE: [motoroladsp] Sections (.bss) , (.rodata) and (.data) ... where and how to place them?

well generally, you can choose whether you want your data to be stored in xflash or pflash, it's up to the initialization, startup, routine to do the proper data move...
 
in the code, the variables will be referenced by the address of the data section they are placed in (plus offset), but physically, they can be stored at any address (this is what the 'AT' command is good for).. so, for example, you want to have the initialized data stored in the xflash

 

.app_data : AT( F__ROM_Address )  # Start data at 0x1000 -> ROM

{

    # .data sections

    F_Begin_Data = .;           # Get start location for RAM

    *(.data)                    # Write data to the section (ROM)

    F_End_Data = .;             # Get end location for RAM

} > .data

 

.app_bss :

{

    # .bss sections

    * (.bss)

 

} >> .data             #append to the .data memory segment

 

 

 

in the startup code, you must move the (F_End_Data - F_Begin_Data) words from the address "F__ROM_Address" to "F_Begin_Data" so the variables get initialized.

 

the second case, when the init values are stored in the pflash is rather more involved. you must declare another memory segment in the p-memory, spanning the same addresses as the data memory segment there the variables should reside (an image memory segment), you will take advantage of the fact that codewarrior doesn't make difference between x-mem and p-mem pointers.

 

.app_data : AT (__data_ROM_addr) # address of the data in p-flash
{

  F_Begin_Data = .;
  * (.data)
  F_End_Data = .;
} > .p_internal_RAM_image        # spans the same addresses as the .data memory segment

.app_bss :
{
 . = . + F_End_Data - F_Begin_Data;   # skip the init-ed variables

  # .bss sections

  * (.bss)

....

} > .data

 

 

if something was still unclear, don't heasitate to ask me,

 

Lubomir

-----Original Message-----
From: Mariano Filippa [mailto:m...@fibertel.com.ar]
Sent: 6. ledna 2004 7:44
To: m...@yahoogroups.com
Subject: [motoroladsp] Sections (.bss) , (.rodata) and (.data) ... where and how to place them?

I've been struggling with (.data), (.bss) and (.rodata) sections. At the end of this message, I have some issues I couldn't figure out. Any help will be greatly appreciated.

 

I did some testing and here are the results. Hope this information is helpful to anybody else.

 

 

Some ELF sections definitions (from targeting manual):

========================================================

 

 (.bss) => segment for uninitialized data. The stationery init code zeroes this area at startup.

 

 (.data) => segment for initialized data here by default.

 

 (.rodata) => segment for constant data, if the project has the write constant data to .rodata section checkbox enabled in target settings.

 

By default, zero-initialized data is put into the .bss section by the compiler (zeroed by INIT code). This behavior can be overriden by using the #pragma explicit_zero_data

 

Results compiling a C file, using Codewarrior 5.1:

========================================================

 

(comments indicate where the variable/constant was placed, taken from ELF symbol table)

 

// **** initialized stuff ****

 

const unsigned int VAR1[3]  = { 0x110A, 0x110B, 0x110C}; // .rodata

const          int VAR2[3]  = { 0x220A, 0x220B, 0x220C}; // .rodata

      unsigned int VAR3[3]  = { 0x330A, 0x330B, 0x330C}; // .data

               int VAR4[3]  = { 0x440A, 0x440B, 0x440C}; // .data

 

const unsigned int VAR5     = 0x5555;   // .rodata

const          int VAR6     = 0x6666;   // .rodata

      unsigned int VAR7     = 0x7777;   // .data

               int VAR8     = 0x8888;   // .data

 

// **** zero-initialized stuff ****

              

const unsigned int VAR9[3]  = { 0x0000, 0x0000, 0x0000}; // .rodata

const          int VAR10[3] = { 0x0000, 0x0000, 0x0000}; // .rodata

      unsigned int VAR11[3] = { 0x0000, 0x0000, 0x0000}; // .bss

               int VAR12[3] = { 0x0000, 0x0000, 0x0000}; // .bss

 

const unsigned int VAR13    = 0x0000;   // .rodata

const          int VAR14    = 0x0000;   // .rodata

      unsigned int VAR15    = 0x0000;   // .bss

               int VAR16    = 0x0000;   // .bss

 

// **** uninitialized stuff ****

              

      unsigned int VAR17[3] ;   // .bss

               int VAR18[3] ;   // .bss

 

      unsigned int VAR19    ;   // .bss

               int VAR20    ;   // .bss 

 

Observations:

========================================================

 

Constants: as expected, all of them are placed into (.rodata), even zero-initialized. These are to be loaded with application.

 

Variables: as expected, initialized stuff goes to (.data) and will be loaded to DSP with application. Zero-initialized stuff goes to (.bss) and will not be loaded with application. Instead, they'll be zeroed by DSP initialize code. Uninitialized variables also go to (.bss).

 

Stuff that I couldn't figure out:

========================================================

 

Where and how to place these sections in memory?

 

For (.rodata) sections, I would place them in (.x_flash_ROM). They are supposed to be constants, they should be downloaded with application and remain there when power goes off. Right?

 

For (.bss) sections, I would place them in (.x_RAM). They are supposed to be R/W and will be initialized after /RESET. Therefore, uninitialized data and zero-initialized data should go here. Right?

 

For (.data)... I read a thousand times "ROM to RAM Copying" in targeting. Still can't figure out. Here's my thinking: (.data) holds initialized variables. I would want them to be downloaded to ROM (to save them when power goes off) and copied to RAM when using them (to be able to R/W).

 

Questions:

 

a) Why "ROM to RAM Copying" specifies to move (.data) to .p_ROM and not .x_ROM ? Why not copying from .xROM to .xRAM ?

 

b) "Targeting" specifies this LCF:

----------------------------

MEMORY {

  .text (RWX) : ORIGIN = 0x8000, LENGTH = 0x0    # code (P)

  .data (RW)  : ORIGIN = 0x3000, LENGTH = 0x0    # data (X)-> RAM

}

 

SECTIONS{

 

F__ROM_Address = 0x1000;        # ROM Starting Address

 

  .main_application :

  {

    # .text sections

    *(.text)

  } > .text

 

  .data : AT( F__ROM_Address )  # Start data at 0x1000 -> ROM

  {

    # .data sections

    F_Begin_Data = .;           # Get start location for RAM

    *(.data)                    # Write data to the section (ROM)

    F_End_Data = .;             # Get end location for RAM

 

    # .bss sections

    * (.bss)

 

  } > .data

}

----------------------------

 

b.1) "F__ROM_Address = 0x1000" does not specify if it is .xROM, .xRAM, etc. What does "AT( F__ROM_Address )" mean ? Shouldn't it be like "F_ROM_Address = .;" inside a (.text) section?

 

b.2) I assume that AT means "put the following sections in F__ROM_Address, but declare them as .data in .xRAM. Is this so?

 

b.3) In my C file, I should do a :

   memcpy( (unsigned long *)&__Begin_Data,

           (const unsigned long *)&__ROMAddress,

           dataLen );

But how to tell the compiler that one address corresponds to .pROM and the other to .xRAM? is it embedded in __Begin_Data and __ROMAddress ?

 

 

I apologize for the extended size of this post. Any help on this will be greatly appreciated. It's 1:30am and I should be sleeping by now, but CodeWarrior has been keeping me awake till late with this mess... I hope I can solve this soon and get my life back to normal :)

 

Regards,

Mariano Filippa



_____________________________________
Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer.  You need to do a "reply all" if you want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join:  m...@yahoogroups.com

To Post:  m...@yahoogroups.com

To Leave: m...@yahoogroups.com

Archives: http://www.yahoogroups.com/group/motoroladsp

More Groups: http://www.dsprelated.com/groups.php3
 Yahoo! Groups Links
 To


Reply by Mariano Filippa ●January 6, 20042004-01-06

I've been struggling with (.data), (.bss) and (.rodata) sections. At the end of this message, I have some issues I couldn't figure out. Any help will be greatly appreciated.

 

I did some testing and here are the results. Hope this information is helpful to anybody else.

 

 

Some ELF sections definitions (from targeting manual):

========================================================

 

 (.bss) => segment for uninitialized data. The stationery init code zeroes this area at startup.

 

 (.data) => segment for initialized data here by default.

 

 (.rodata) => segment for constant data, if the project has the write constant data to .rodata section checkbox enabled in target settings.

 

By default, zero-initialized data is put into the .bss section by the compiler (zeroed by INIT code). This behavior can be overriden by using the #pragma explicit_zero_data

 

Results compiling a C file, using Codewarrior 5.1:

========================================================

 

(comments indicate where the variable/constant was placed, taken from ELF symbol table)

 

// **** initialized stuff ****

 

const unsigned int VAR1[3]  = { 0x110A, 0x110B, 0x110C}; // .rodata

const          int VAR2[3]  = { 0x220A, 0x220B, 0x220C}; // .rodata

      unsigned int VAR3[3]  = { 0x330A, 0x330B, 0x330C}; // .data

               int VAR4[3]  = { 0x440A, 0x440B, 0x440C}; // .data

 

const unsigned int VAR5     = 0x5555;   // .rodata

const          int VAR6     = 0x6666;   // .rodata

      unsigned int VAR7     = 0x7777;   // .data

               int VAR8     = 0x8888;   // .data

 

// **** zero-initialized stuff ****

              

const unsigned int VAR9[3]  = { 0x0000, 0x0000, 0x0000}; // .rodata

const          int VAR10[3] = { 0x0000, 0x0000, 0x0000}; // .rodata

      unsigned int VAR11[3] = { 0x0000, 0x0000, 0x0000}; // .bss

               int VAR12[3] = { 0x0000, 0x0000, 0x0000}; // .bss

 

const unsigned int VAR13    = 0x0000;   // .rodata

const          int VAR14    = 0x0000;   // .rodata

      unsigned int VAR15    = 0x0000;   // .bss

               int VAR16    = 0x0000;   // .bss

 

// **** uninitialized stuff ****

              

      unsigned int VAR17[3] ;   // .bss

               int VAR18[3] ;   // .bss

 

      unsigned int VAR19    ;   // .bss

               int VAR20    ;   // .bss 

 

Observations:

========================================================

 

Constants: as expected, all of them are placed into (.rodata), even zero-initialized. These are to be loaded with application.

 

Variables: as expected, initialized stuff goes to (.data) and will be loaded to DSP with application. Zero-initialized stuff goes to (.bss) and will not be loaded with application. Instead, they'll be zeroed by DSP initialize code. Uninitialized variables also go to (.bss).

 

Stuff that I couldn't figure out:

========================================================

 

Where and how to place these sections in memory?

 

For (.rodata) sections, I would place them in (.x_flash_ROM). They are supposed to be constants, they should be downloaded with application and remain there when power goes off. Right?

 

For (.bss) sections, I would place them in (.x_RAM). They are supposed to be R/W and will be initialized after /RESET. Therefore, uninitialized data and zero-initialized data should go here. Right?

 

For (.data)... I read a thousand times "ROM to RAM Copying" in targeting. Still can't figure out. Here's my thinking: (.data) holds initialized variables. I would want them to be downloaded to ROM (to save them when power goes off) and copied to RAM when using them (to be able to R/W).

 

Questions:

 

a) Why "ROM to RAM Copying" specifies to move (.data) to .p_ROM and not .x_ROM ? Why not copying from .xROM to .xRAM ?

 

b) "Targeting" specifies this LCF:

----------------------------

MEMORY {

  .text (RWX) : ORIGIN = 0x8000, LENGTH = 0x0    # code (P)

  .data (RW)  : ORIGIN = 0x3000, LENGTH = 0x0    # data (X)-> RAM

}

 

SECTIONS{

 

F__ROM_Address = 0x1000;        # ROM Starting Address

 

  .main_application :

  {

    # .text sections

    *(.text)

  } > .text

 

  .data : AT( F__ROM_Address )  # Start data at 0x1000 -> ROM

  {

    # .data sections

    F_Begin_Data = .;           # Get start location for RAM

    *(.data)                    # Write data to the section (ROM)

    F_End_Data = .;             # Get end location for RAM

 

    # .bss sections

    * (.bss)

 

  } > .data

}

----------------------------

 

b.1) "F__ROM_Address = 0x1000" does not specify if it is .xROM, .xRAM, etc. What does "AT( F__ROM_Address )" mean ? Shouldn't it be like "F_ROM_Address = .;" inside a (.text) section?

 

b.2) I assume that AT means "put the following sections in F__ROM_Address, but declare them as .data in .xRAM. Is this so?

 

b.3) In my C file, I should do a :

   memcpy( (unsigned long *)&__Begin_Data,

           (const unsigned long *)&__ROMAddress,

           dataLen );

But how to tell the compiler that one address corresponds to .pROM and the other to .xRAM? is it embedded in __Begin_Data and __ROMAddress ?

 

 

I apologize for the extended size of this post. Any help on this will be greatly appreciated. It's 1:30am and I should be sleeping by now, but CodeWarrior has been keeping me awake till late with this mess... I hope I can solve this soon and get my life back to normal :)

 

Regards,

Mariano Filippa