CODEWITHSUNDEEP
cassemblyembeddedmicrocontrollerboot
Renjith G
Renjith G

Reputation: 4908

Flow of Startup code in an embedded system , concept of boot loader?

I am working with an embedded board , but i don't know the flow of the start up code(C/assembly) of the same.

Can we discuss the general modules/steps acted upon by the start up action in the case of an embedded system.

Just a high level overview(algorithmic) is enough.All examples are welcome.

/Kanu__

Upvotes: 11

Views: 28516

Answers (5)

Rishad
Rishad

Reputation: 11

Functions of Startup Code for C/C++

  1. Disables all interrupts
  2. Copies any initialized data from ROM to RAM
  3. Uninitialized data area is set to zero.
  4. Allocates space for and initializes the stack
  5. Initializes the processor’s stack pointer
  6. Creates and initializes the heap
  7. Executes the constructors and initializers for all global variables (C++ only)
  8. Enables interrupts
  9. Calls main

Upvotes: 1

Jijo
Jijo

Reputation: 1

Where is "BOOT LOADER" placed then? It should be placed before the start-up code right? As per my understanding, from the reset vector the control goes to the boot loader. There the code waits for a small period of time during which it expects for data to be flashed/downloaded to the controller/processor. If it does not detect a data then the control gets transferred to the next step as specified by theatrus. But my doubt is whether the BOOT LOADER code can be re-written. Eg: Can a UART bootloader be changed to a ETHERNET/CAN bootloader or is it that data sent using any protocol are converted to UART using a gateway and then flashed.

Upvotes: 0

zdav
zdav

Reputation: 2758

Pretty open-ended question, but here are a few things I have picked up.

For super simple processors, there is no true startup code. The cpu gets power and then starts running the first instruction in its memory: no muss no fuss.

A little further up we have mcu's like avr's and pic's. These have very little start up code. The only thing that really needs to be done is to set up the interrupt jump table with appropriate addresses. After that it is up to the application code (the only program) to do its thing. The good news is that you as the developer doesn't generally have to worry about these things: that's what libc is for.

After that we have things like simple arm based chips; more complicated than the avr's and pic's, but still pretty simple. These also have to setup the interrupt table, as well as make sure the clock is set correctly, and start any needed on chip components (basic interrupts etc.). Have a look at this pdf from Atmel, it details the start up procedure for an ARM 7 chip.

Farther up the food chain we have full-on PCs (x86, amd64, etc.). The startup code for these is really the BIOS, which are horrendously complicated.

Upvotes: 3

Yann Ramin
Yann Ramin

Reputation: 33197

  1. CPU gets a power on reset, and jumps to a defined point: the reset vector, beginning of flash, ROM, etc.
  2. The startup code (crt - C runtime) is run. This is an important piece of code generated by your compiler/libc, which performs:
    1. Configure and turn on any external memory (if absolutely required, otherwise left for later user code).
    2. Establish a stack pointer
    3. Clear the .bss segment (usually). .bss is the name for the uninitialized (or zeroed) global memory region. Global variables, arrays, etc which don't have an initializing value (beyond 0) are located here. The general practice on a microcontroller is to loop over this region and set all bytes to 0 at startup.
    4. Copy from the end of .text the non-const .data. As most microcontrollers run from flash, they cannot store variable data there. For statements such as int thisGlobal = 5;, the value of thisGlobal must be copied from a persistent area (usually after the program in flash, as generated by your linker) to RAM. This applies to static values, and static values in functions. Values which are left undefined are not copied but instead cleared as part of step 2.
    5. Perform other static initializers.
    6. Call main()

From here, your code is run. Generally, the CPU is left in an interrupts-off state (platform dependent).

Upvotes: 27

marr75
marr75

Reputation: 5725

The big question is whether or not your embedded system will be running an operating system. In general, you'll either want to run your operating system, start up some form of inversion of control (an example I remember from a school project was a telnet that would listen for requests using RL-ARM or an open source tcp/ip stack and then had callbacks that it would execute when connections were made/data was received), or enter your own control loop (maybe displaying a menu then looping until a key has been pressed).

Upvotes: 1

Related Questions