Path: EDN Asia >> News Centre >> IC/Board/Systems Design >> Behind the scenes of MCU start-up code
IC/Board/Systems Design Share print

Behind the scenes of MCU start-up code

06 Apr 2016  | Jacob Beningo

Share this page with your friends

Having firmware run on a microcontroller debugger involves many things beyond the almost magical flickers on screen that precede the appearance of a single line of code with the highlighted word, main. Let's take a look at what goes on before that happens.

Once the program has been loaded onto the microcontroller, the microprocessor starts execution by first reading the reset vector. The reset vector holds the memory address of where the first instructions for the program are located. These first instructions aren't the start of the application that exist in main, however, but instead are usually initialisation routines hidden away in start-up code.

The start-up code performs a number of critical functions that are necessary to prepare the microcontroller to start executing the developers' application. The exact steps the start-up code follows will vary slightly from one microcontroller to the next, but generally one of the first steps is to initialise the system clock. Once the system clock has stabilised, the memory environment must be set up by copying initialised variables into RAM. This process is often referred to as "C copy down." The idea is that the microcontroller's memory is being set up to run the C environment that the application code will run under.

The start-up code will also initialise the stack pointer. The stack is an area of memory that will store automatic variables, function parameters, interrupt frames, and function return addresses. A bare-metal system (a system that doesn't have an RTOS) will have only a single stack area that, by default, is typically sized to a depth of 0x400. The start-up code will often have a few assembly language instructions designed to set the top of the stack pointer.

Once the clock has been initialised, the C copy down performed and the top of the stack has been identified, the last step is to either jump to or call main. Some start-up code will perform a jump to main rather than a function call to main because this can save a few precious bytes of stack space. No matter which method is used, though, a developer will then find themselves at the beginning of mainwith the debugger halted and waiting for permission to execute the application.

And yet, a developer is usually completely unaware of all the code that has executed prior to reaching the beginning of main. Should a developer uncheck the "run to main" option, though, rather than breaking at the first line of main the application will instead break on the first instruction of the start-up code. A developer can then step through each line of code that is used to setup the processor before main is ever reached. As one might expect, the start-up code is usually different from one development environment to the next. At the beginning of a project it is often useful to step through the start-up code because one never knows what interesting things might be set up before ever reaching main.

The start-up code for a microcontroller can become more complicated if there is a bootloader in the mix. When the application boots, there may be a piece of code that performs a quick check to determine whether the primary application should be executed or whether a firmware update application should be executed instead. If the bootloader is executed to update firmware or to simply start the system in a known state and perform a system sanity check, the start-up code may need to reset the stack pointer rather than simply initialising it.

Embedded software developers used to know every nook and cranny of their software. Since microcontrollers have gone 32-bit, the way in which firmware is developed has rapidly changed. Details of how the processor starts up and the code executes are only the first pieces of code to begin hiding behind in the scenes. One day, embedded developers may know only as much about what's happening at the microcontroller level as an application developer understands what is happening at the microprocessor level of a server. Despite what seems like a loss of insight, though, the levels of abstraction and hidden code will undoubtedly help developers write code faster and at lower cost while apparent magic works behind the scenes.

Want to more of this to be delivered to you for FREE?

Subscribe to EDN Asia alerts and receive the latest design ideas and product news in your inbox.

Got to make sure you're not a robot. Please enter the code displayed on the right.

Time to activate your subscription - it's easy!

We have sent an activate request to your registerd e-email. Simply click on the link to activate your subscription.

We're doing this to protect your privacy and ensure you successfully receive your e-mail alerts.

Add New Comment
Visitor (To avoid code verification, simply login or register with us. It is fast and free!)
*Verify code:
Tech Impact

Regional Roundup
Control this smart glass with the blink of an eye
K-Glass 2 detects users' eye movements to point the cursor to recognise computer icons or objects in the Internet, and uses winks for commands. The researchers call this interface the "i-Mouse."

GlobalFoundries extends grants to Singapore students
ARM, Tencent Games team up to improve mobile gaming

News | Products | Design Features | Regional Roundup | Tech Impact