EmbDev.net

Forum: ARM programming with GCC/GNU tools .data sections load address and execution address


Author: Frank Mx (dizzyone)
Posted on:

Rate this post
0 useful
not useful
I started arm development with a self build board with a tms470 from ti.
The first what I had to do was to read many documents about building an
executable with gcc. I'm a bit expirienced with the command line tools
and the entire build process from my development with atmels avrs. But
with the arm development there where some new tasks. I had to provide my
own startup code and I had to apply a appropriate linker script.
The linker script is because of different sections which have to be
paced on different positions in the memory of the device. The .text
section which containes the executable code has to be placed in flash
while the .bss section which contains uninitialized variables has to be
placed in ram. The .data section which contains initialized data is a
bit special. It has two addresses. One addrss (the load address or LMA)
has to be placed in flash. This is the address, where the initial values
are stored. This address the data section has to be loaded to on
flashing the device. While running the processor should also be able to
write the variables. That's why we need a second address for this
section (the execution address or VMA). All instructions within that
image refere only the execution adresses oft those variables. But how
come the variables from the LMA to their VMA? Here comes the startup
code into the game. It copies the whole .data section from its load
address to its execution address. So far, so good, I get all fliles
compiled and linked into one elf image. Also the map file tells me that
the .data section has different addresses for load and execution. My
problem now is the following:

When I want to debug my very sipmle code within the simulator of the
gdb/insight, all variables of the .data section are placed already on
their execution addresses and the load addresses are empty (NULL). If
now the startup code copies the .data section it overwrites the correct
values with zeros.
Why goes this wrong? There is nothing else target specific than the
ioheader.

Thanks in advance for your answers.

Author: Helmut Ruoss (Guest)
Posted on:

Rate this post
0 useful
not useful
Hi Frank,
thank you very much for your topic Thank YOU for helping me...
Sorry that I can't help you, but possibly you could write which tools
you are using. I tried WINARM but had no success to compile anything of
the already written examples. WinAVR (wich I also use) seems to be quite
simple compared to WINARM....
I use LPC2129 with WinXP.
Thabks in advance for an answer,
Helmut



frank mx wrote:
> I started arm development with a self build board with a tms470 from ti.
> The first what I had to do was to read many documents about building an
> executable with gcc. I'm a bit expirienced with the command line tools
> and the entire build process from my development with atmels avrs. But
> with the arm development there where some new tasks. I had to provide my
> own startup code and I had to apply a appropriate linker script.
> The linker script is because of different sections which have to be
> paced on different positions in the memory of the device. The .text
> section which containes the executable code has to be placed in flash
> while the .bss section which contains uninitialized variables has to be
> placed in ram. The .data section which contains initialized data is a
> bit special. It has two addresses. One addrss (the load address or LMA)
> has to be placed in flash. This is the address, where the initial values
> are stored. This address the data section has to be loaded to on
> flashing the device. While running the processor should also be able to
> write the variables. That's why we need a second address for this
> section (the execution address or VMA). All instructions within that
> image refere only the execution adresses oft those variables. But how
> come the variables from the LMA to their VMA? Here comes the startup
> code into the game. It copies the whole .data section from its load
> address to its execution address. So far, so good, I get all fliles
> compiled and linked into one elf image. Also the map file tells me that
> the .data section has different addresses for load and execution. My
> problem now is the following:
>
> When I want to debug my very sipmle code within the simulator of the
> gdb/insight, all variables of the .data section are placed already on
> their execution addresses and the load addresses are empty (NULL). If
> now the startup code copies the .data section it overwrites the correct
> values with zeros.
> Why goes this wrong? There is nothing else target specific than the
> ioheader.
>
> Thanks in advance for your answers.

Author: Karsten (Guest)
Posted on:

Rate this post
0 useful
not useful
Hello Frank,

welcome on board!

I started also my arm development with the TMS470 processor.
I don't know what you mean with LMA and VMA. Couldt you explain this?

In the moment I can run and debug my own programs in the RAM of the
TMS470.
I use Eclipse as IDE and a USB-JLink-Adapter for the connection to my
development board. The connection beetween the JLink-Adapter und Eclipse
is realized with an open source gdb server. You can also use this server
for the connection to gdb/insight.
The next step is the development of the flash loader.

Ok, I hope we can exchange some information about the development for
the TMS470.
Because this is a very new processor, the information on the www is very
small.

Best regards
Karsten

Author: Martin Thomas (Guest)
Posted on:

Rate this post
0 useful
not useful
frank mx wrote:

> When I want to debug my very sipmle code within the simulator of the
> gdb/insight, all variables of the .data section are placed already on
> their execution addresses and the load addresses are empty (NULL). If
> now the startup code copies the .data section it overwrites the correct
> values with zeros.

You might look into the examples for LPC2xxx. You will see that the
startup-code has some sections with #ifdef RAM_RUN (or #ifdef ROM_RUN).
Just "envelop" the .data-copy-routine with #ifdef ROM_RUN/#endif and do
not define ROM_RUN. So the coping will not be done for the
"debug-image". For a "flash-image" define ROM_RUN (-DROM_RUN) to enable
the the copy-routine for .data from flash to RAM.

Hope this helps,
Martin Thomas

Reply

Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]




Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.