Hello, I written simple c program mention below by selecting the lpc2148 chip but not include its startup file in the project. when i run it will go in infinite loop. I also put the break point but i think its not coming to that execution line. Is it necessary to include startup file? void main() { int a=2,b=3,c; c= a+b; }
To Per:
"Some processors (like 8051 and ARM chips) don't contain any logic to locate any main() function on startup."
Could you give an example of a processor containing some kind of logic designed to locate the main() at startup?
Regards, Nikolay.
A processor can't locate main for the simple reason that the name "main" is stripped away when the binary is created.
Different processors have different rules for what they do on startup, but they normally jump to a fixed address (possibly controlled by external means - sampling processor pins while booting) or loading a jump vector from a fixed address and then jumping to this loaded address.
Some processors can do a bit more before they jump to a startup function - for example prepare an initial stack. Some processors have fixed RAM so they just give the stack pointer a suitable hard-coded value on reset. This is very common for all-in-one microcontrollers. Some processors can look at a specific address in memory to find what value to use for initial stack. Look for example at the boot sequence of a Cortex-M3 chip.
If the compiler/linker just makes sure that main() is placed at a specific address, or creates a vector pointing to main(), then just about any processor can manage to jump to main on reset. It would normally be a jump - not a call - so it would not go well if main() tries to return. But then again - main() is normally expected to contain an infinite loop for embedded projects.
What is important here is that no processor will be able to enter main() directly, and deliver a fully initialized "C program" environment. Somewhere far off in dusty memory I have seen some processor clearing RAM on boot. But that is extremely unusual since it either requires the processor to have loop mechanism to loop through all memory cells - this increases the time until the developer gets a chance to run his first instructions. The other alternative is that the cihp have special RAM with a reset feature connected to the individual memory cells which costs money and chip size.
With or without zeroed memory, the processor itself can not know what global variables that are supposed to have non-zero initial values. Or what function calls the CRTL is expecting to be made before you enter main().
In the end, the majority of processors requires initial assembler code to setup the processor enough that it is even meaningful to reach a main(). But some processors understands enough of the calling models of C etc, that you can have 100% C code.
So in the end, there are lots of alternatives possible.
Having a specific startup file that you need to link with the project. This is the most common, since embedded developers likes full control and want/need to play around with lots of specifics before the "normal" code starts.
Have the tools auto-generate the startup instructions. This is less common because it is a quite strict integration between compiler and processor. So it is normally only done for more minimalistic processors where there aren't so much interesting things to play with in the processor.
Have the processor directly enter a specific C function (that could be named main() or something else) that sets up everything. Very nice, given how more and more developers don't understand assembler programming, but the majority of processors haven't an enough friendly startup logic.
Another thing here is that more and more processors starts to have a primary boot loader, so the initial instructions run aren't our program code or our/compiler vendors startup code. Processors with an initial boot loader can have any number of extra featues affecting the startup of a program. They may look at hw ports for loading potentially encrypted firmware binaries from USB, memory cards, ... They can support multi-boot where it selects one of multiple binaries to boot based on previous performance - allowing redundant programs. With such boot loaders, there can be lots of tabulated data that the boot loader may look at when selecting/starting the program or potentially also vectoring interrupts. But I have never seen such a boot loader that takes named text strings as tokens, so the processor/boot loader would still not know about a specific main() in the end-user program. It would still assume that compiler+linker places the first code at a fixed location or points a vector to teh first code to run. If that code is named main() or not is irrelevant.