Hi,

sorry if my answers are too basic, but you dit not told how experienced
you are in embedded programming, and some of your questions can be
understood as if you would not be too experienced.

Drasko DRASKOVIC wrote:
> Hi all,
> since I am just starting with my lpc2148 board, I have two beginner
> question:
> 1) I noticed that all given examples that came with this board are in .hex
> format. Do I always have to compile into this format? Or can I flash ELF
> format in my chip?
>
You are not using .hex or .elf in your chip. The chip is executing a
binary image which is usually made by the down loader tool. Most
embedded systems do not have an executable loader like windows for .exe
files. So there is nothing on-chip for doing the relocation and a like.
This is why linking is more complicated for embedded systems, because
the linker will do the relocation of your software modules and thus it
needs to know where to place them. Also you need to take care of
different memory types (read write, read only, etc..).

> 2) Also, these examples came precompiled, and flash them with some Windows
> flash utility that came with this board. From this flash utility, I can not
> tell from which to which address it is flashing, so can anybody tell me
> which addreses ahve to be set up if I want to use another tool.
>
In reflection of the above, the .elf and .hex file contains all
addresses the flash programmer needs. So why would it bother you with
addresses?

> 3) I asked question #2 because I am not sure with the concept of startup
> code - I never flash this. All I flash is this precompiled .hex example, so
> I am afraid not to overwrite some part of the memory that I am not supposed
> to. Also, I noticed in my uVision IDE that it gives startup code for every
> new project. Where and how this code is compiled and to which addresses and
> how it is flashed?
>
If you are using a JTAG interface for debugging, you don't need to
worry. You can (nearly) always reprogram the chip over the JTAG interface.

The startup code is part of you application. Most compiler come with
their own working version because these things are highly compiler
dependent.
The startup does the following things:

* Set stack pointers
C depends on function calls and thus the stack pointer must be
properly configured before calling main. This is a must, and needs
to be done from assembly.
* memory content initialization
this is not absolute necessary. You can write your program in a
way to be able to avoid this step. For example if you have an init
call for all your software modules, and these calls are setting
initial values.
Most application will put the non initialized global (.bss)
variables and the initialized global variables (.data) to their
own memory section. The linker is generation symbols to the start
and the end of these sections. Thus a C or assembly routine can
access them. For .bss the routine will fill the area with zeros.
For .data the thing is a bit more complicated. For .data the
linker is generating a copy of the segment and puts it to FLASH.
This images then copied over real .data section by the mentioned
routine.
* Now main() can be called.

This is the most basic case. For example if you have to deal with
external SDRAM, then before the memory content initialization, or even
before setting the stack pointer you need to start the external memory
interface. This may need a proper core clock setting. This case you need
to configure a lot of on-chip hardware from the assembly startup code.

I prefer to do most hardware configuration from C code. Thus my assembly
startup will only configure the stack and then call a low_level_init()
and the main(). low_level_init() will configure the hardware, and to the
memory content initialization.

There are some other things you may need to do from assembly. For most
cores (ARM cores too) you need special stack handling for exception
routines. Some prefer to do this from assembly and some from C. If you
want to do that from C, then you need to use some non ANSI language
extension of the compiler. So your code can not be portable (either
because of assembly or because of the C extensions). Sooner or later you
will face the need to deeply understand the startup files and the
interrupt system. So after having fun with the demo app, I would start
investigating this.

Foltos


> Thank you for your time and explanations.
>
> Best regards,
> Drasko DRASKOVIC
>
>
>
>


[Non-text portions of this message have been removed]