Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

what happens after powering up uC?

Status
Not open for further replies.

raedbenz

New Member
Hi,,
i would like to know what is the booting procedure in a microcontroller after since you power it up until it goes to the main function of your program?
 
That depends on the uC and how your "main" program was constructed. Most processors have a RESET line. As long as RESET is in the active state the processor does nothing except run the oscillator and place all registers in a defined state. There may be some parts that are defined to be in an unknown state, that will require subsequent initialization. If you read the datasheet carefully, at least you know which parts they are. When RESET is released and goes to its inactive state the processor will go to a fixed address or fetch an address from a fixed address and begin executing instructions.

If your program is written in assembly language you've arrived. It's all up to you.

On the other hand if you're using a C-compiler, then it will have linked a piece of code called "cstartup" or some such thing, that will initialize the stack pointer, initialize variables that have a non-zero initial value, clear all the uninitialized values, and perform any other initialization required and finally call main(). In most embedded systems main() is not expected to return. If it does most compilers have an infinite loop after the call to main.

Your compiler should have the "cstartup" code in soure form somewhere; track it down and decode it some rainy Sunday afternoon.

Does that answer your question?
 
That depends on the uC and how your "main" program was constructed. Most processors have a RESET line. As long as RESET is in the active state the processor does nothing except run the oscillator and place all registers in a defined state.

While the device is in reset, the oscillator won't run, and it won't set anything up - things only start happening once the oscillator is running. It would also be unusual for the processor to perform any 'setting up', the person writing the program normally has to do that.
 
Typically there is a reset vector that it starts at when it starts running. This reset vector simply holds a GOTO with an address that you give it. From there it jumps to the address you give and runs whatever program you have there.
 
In c the start up function is often called c0 or similar. In the C18 compiler it is called c018.

All high level languages require a similar routine to setup the stack etc. Many hide it from the user.

Keep in mind that c0 runs after the processor has started.
 
While the device is in reset, the oscillator won't run, and it won't set anything up - things only start happening once the oscillator is running. It would also be unusual for the processor to perform any 'setting up', the person writing the program normally has to do that.
I believe the AVR oscillators run in RESET, and the internal RESET remains active for a predetermined interval after the external sources have gone inactive. This is accomplished by counting oscillator cycles.

There are prescribed initial values for many of the special function registers. It is also true that some bits in some registers are undefined. From the ATmega128 datasheet.

https://www.electro-tech-online.com/custompdfs/2009/06/doc2467.pdf
During Reset, all I/O registers are set to their initial values, and the program starts execution
from the Reset Vector.
...
The I/O ports of the AVR are immediately reset to their initial state when a reset source goes
active. This does not require any clock source to be running.

After all reset sources have gone inactive, a delay counter is invoked, stretching the internal
reset. This allows the power to reach a stable level before normal operation starts. The time-out
period of the delay counter is defined by the user through the CKSEL fuses. The different selections
for the delay period are presented in “Clock Sources” on page 37.
I think even your precious PIC processors have defined reset states for many registers in the register file. I know of no processor that does not set some number of internal registers to known states on exit from RESET. I think you are just wrong on both points for some processors. You may be correct about the oscillator being stopped on some processors, but any processor that can take an external oscillator probably isn't one of them.

If you were to say that a processor does not fetch and execute instructions while in RESET I'd be inclined to agree. I think I remember that many processors from the Motorola(Freescale) family will run repeated bus READ cycles fetching the RESET vector at address 0xFFFE and 0xFFFF before RESET is released.

3VO may remeber the behavior of the 6502. It's just been too many years, but I don't hink it was possible or advisable to stop the oscillator while in RESET.

Edit: Trust in Google search
https://www.electro-tech-online.com/custompdfs/2009/06/synertek_hardware_manual.pdf

Check out page 35, Figure 1.13 which shows the φ2 clock beating up and down before the rising edge of RES-bar. The web has absolutely everything!
 
Last edited:
I believe the AVR oscillators run in RESET, and the internal RESET remains active for a predetermined interval after the external sources have gone inactive. This is accomplished by counting oscillator cycles.

There are prescribed initial values for many of the special function registers. It is also true that some bits in some registers are undefined. From the ATmega128 datasheet.

https://www.electro-tech-online.com/custompdfs/2009/06/doc2467-1.pdf

I think even your precious PIC processors have defined reset states for many registers in the register file. I know of no processor that does not set some number of internal registers to known states on exit from RESET. I think you are just wrong on both points for some processors. You may be correct about the oscillator being stopped on some processors, but any processor that can take an external oscillator probably isn't one of them.

I've never used (or seen) a micro-controller that runs the oscillator during reset - if you're using an external oscillator obviously that runs, but it doesn't do anything inside the chip.

PIC's don't run during reset, 6502's don't, nor do 68000's, and every processor in every item of equipment I've had occasion to check doesn't run during reset either. Typical fault finding on processor based equipment (TV's, VCR's etc.) - check the oscillator is running (using x10 probe only), if not, next check the reset line - quite often the reset line will be held low by something else, preventing the oscillator running.

While some registers 'may' power-up in a defined state, there's no code running to make that happen, and you certainly shouldn't trust what values might be there.
 
First I would like to say that I tried to stay out of this. Based on the posts in this thread none of us know enough about the internal working of the uC's to debate what is real. To make it worse, I would expect the documentation to tell what you will see, rather then how it is accomplished. It may even tell a few white lies in the name of simplification.
While some registers 'may' power-up in a defined state, there's no code running to make that happen, and you certainly shouldn't trust what values might be there.
I find it hard to believe you wrote that. When a data sheet provides data on the state of a register at power up it can be trusted.

My guess is that most often the processor and peripheral designers use logic that does not require the system clock to place registers into their power up state.

On a micro coded processor it makes sense to use a microcode start up sequence to initialize the system as it comes out of reset. I do not know which if any of the current uC's are microcoded machines.

I would not be surprised to see a non microcoded processor use a set of initialization instructions. If the start up memory existed outside of the published memory map we would be mostly, if not totally, clueless about its existence. Given that the system could execute start up code using an internal oscillator the external oscillator pins may provide no useful information.
 
First I would like to say that I tried to stay out of this. Based on the posts in this thread none of us know enough about the internal working of the uC's to debate what is real. To make it worse, I would expect the documentation to tell what you will see, rather then how it is accomplished. It may even tell a few white lies in the name of simplification.

I would certainly agree with that, you can only estimate what's happening from the outside conditions.

I find it hard to believe you wrote that. When a data sheet provides data on the state of a register at power up it can be trusted.

Surely you're not so naive as to believe datasheets are faultless?, don't assume anything - set it yourself. The number of errors in datasheets is legendary, and they don't even seem to bother correcting the errors in later editions.
 
Well thank you all guys..

but where is the role of boot loader in the start-up of a microcontroller?
is it the "cstartup"??

thanks
 
Well thank you all guys..

but where is the role of boot loader in the start-up of a microcontroller?
is it the "cstartup"??

It has no role as such, but if you install a bootloader then that will run instead of the main program, check if you are loading another program, else jump to the main program.

A bootloader is usually just a program you install, that allows you to load other programs without a programmer (you do need a programmer to install the bootloader though), although some devices do come with a bootloader already installed.
 
I never said that the processor runs instructions during RESET, but the oscillator will beat up and down. From the 16F128A datasheet the only thing that shuts off the oscillator is SLEEP(see figure 14-1). The OP asked a reasonable question and we have a difference of opinion on the answer. If the answer is important it is easy enough to put a scope on the oscillator and see.

As a matter of policy I always code initialization routines to explicitly set registers to initial values that are appropriate to an application, even if it happens to be the same value as specified by the hardware RESET. It's cheap insurance.
 
I never said that the processor runs instructions during RESET, but the oscillator will beat up and down. From the 16F128A datasheet the only thing that shuts off the oscillator is SLEEP(see figure 14-1). The OP asked a reasonable question and we have a difference of opinion on the answer. If the answer is important it is easy enough to put a scope on the oscillator and see.

I have done so many times, on a PIC 16F628, and many other different kinds of processors, which is why I know the oscillator doesn't run during reset.

It's also absolutely vital on a PIC, because you can't enter programming mode if the oscillator is running - this is what causes programing problems with a 16F628 if you set the internal oscillator.

As a matter of policy I always code initialization routines to explicitly set registers to initial values that are appropriate to an application, even if it happens to be the same value as specified by the hardware RESET. It's cheap insurance.

Likewise.
 
Surely you're not so naive as to believe datasheets are faultless?, don't assume anything - set it yourself. The number of errors in datasheets is legendary, and they don't even seem to bother correcting the errors in later editions.
I am in agreement, I read your original statement to be overly strong, and it is not.

We were taught to practice paranoid programming, aka belt and suspenders programming.
 
A bootloader is a regular program just like anything else. Typically it is first run when the microcontroller starts up, reads an input for a signal, and if no signal is received runs the regular program after the bootloader. If a signal is present, it reads the signal and writes to its own memory to write a new program after the bootloader.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top