I know that for a regular PC, BIOS executes its handler of interrupt 0x19 to search for a bootable device and if a device is found, first 512 bytes are loaded at 0x7c00 and BIOS starts execute from that address. 0x19 and 0x7c00, although are standard, are defined by BIOS manufacture.

Since microcontroller does not use external device like a hard drive to boot but use its flash memory, how do I know where is it going to load and execute bootloader code in flash memory? And using what interrupt? Is there any document, i.e. I have a TM4C123 microcontroller, what relevant documents do I need to look at to write a bootloader?

A microcontroller, just like any other CPU, starts executing code from a fixed address. That address is often known as the "reset vector".

The address will be in the datasheet for the microcontroller.

Even on a PC it works like that. The "booting" off a hard drive is about number 10347 in its list of things to do when it starts - the first is to execute code from ROM, just like a microcontroller does from Flash.

• In the embedded world, especially with embedded bootloaders, micros do not begin executing code from a fixed address. Rather, it is often adjustable (through various mechanisms) in order to support the two programs (user code and the bootloader) co-existing on the device. – Nick T Jan 11 '15 at 7:11
• Once programmed, the reset vector NEVER changes. Ever. Yes, there may be ways of changing it DURING programming, but that is completely irrelevant. Once the chip is programmed it is fixed until you reprogram the chip. It's all covered by the second paragraph of my answer, which can be summarised as: Read the datasheet! – Majenko Jan 11 '15 at 11:22
• @Majenko : you might be a little wrong about the reset vector never changing. There are microcontrollers where you can change the reset vector from the application (some Atmel chips, for example). There is a fuse which can be set during programming, which decides how the reset vector is initialized, but you can change it later during the execution of your program, so that any reset source except a cold start will use the new reset vector. – vsz Jan 11 '15 at 19:32
• @vsz I think we may be straying a little off the point and arguing over semantics here. So what if there is a mechanism to change where the reset vector is? That doesn't change the fact that the execution starts at a memory location, not by triggering a software interrupt which then loads the bootloader into memory. I refuse to get drawn into this kind of pedantic crap that is constantly going around where you focus in on one specific word which you then take out of context and argue over. It's completely pointless and has absolutely no bearing whatsoever on the question. – Majenko Jan 11 '15 at 19:38
• @Majenko I was only referring to your comment where you stated that "Once programmed, the reset vector NEVER changes. Ever." which is wrong and can cause confusion. With your answer I'm completely OK. No need for such an aggressive tone, especially as we probably never communicated before, so I don't know why you are accusing me of "constant" arguing. – vsz Jan 11 '15 at 20:08

There may be some confusion around the term "bootloader", which is used very differently in the context of embedded systems vs. "desktop" systems.

First of all, the code that any processor executes following a reset must already be in memory, at a particular fixed address that's determined by the specific processor being used. In an embedded system, this code will be the actual application code, placed there previously by programming the nonvolatile memory, possibly using a bootloader (sense 1).

In a desktop system, the operating system and any application code are typically loaded from some form of secondary storage (i.e., storage from which the processor cannot directly execute code) into volatile RAM. On this type of system, the code that gets executed after a reset is the BIOS code, located in a ROM of some type on the motherboard. One of the functions of the BIOS is to bootload (sense 2) the operating system. The BIOS contains enough code to be able to access the various forms of secondary storage, find the file that contains the operating system kernel, copy it into RAM and then jump to it. What happens after that is up to the kernel. This whole process occurs every time the system is turned on or gets a hardware reset.

Getting back to sense 1 of bootloader, this is code that is part of what is already loaded into the embedded processor's nonvolatile storage, and is specifically designed to accept new application code from an external source and copy it into the processor's nonvolatile memory. This process only needs to occur when it is desired to change the application code for some reason. Otherwise, the same application code gets executed each time the processor is turned on or reset.

Bootloaders in embedded systems can be slightly different from general purpose computers in that you can configure the processor (in a space apart from the code memory, often "fuses") to begin execution from a different memory address. What this permits is injection of code (the bootloader) that can watch for a special signal to do something different (typically for reprogramming the device). If the signal is not seen, the bootloader typically redirects to the traditional boot address and things continue on as normal.

What the adjustable boot location allows is a single, fixed binary to work with and without a bootloader, so long as when the main program is compiled it doesn't overlap with the memory used for the bootloader. So when programming the device, there are two rough options:

1. Program the device with just the main program and leave the bootloader fuse alone. On reset the processor begins execution of the main program at the normal location.
2. Program the device with the (unmodified) main program and the bootloader, and set the bootloader fuse as appropriate. On reset the processor begins execution at the bootloader, which can do something (e.g. reprogramming) or nothing (pass control to the normal location).

If the processor doesn't have a bootloader fuse and you want a bootloader, it's a bit more complicated, but still possible (e.g. ATtiny bootloaders).

In any event, embedded systems don't need a bootloader like computers. When the processor powers up or otherwise resets, a reset interrupt is triggered, which (should) reinitialize the memory and peripherals to the state specified in the datasheet. On an AVR, the program counter is just set to 0, so the processor grabs whatever's there and goes. If you're using any interrupts, typically the first bunch of memory addresses are all JMP xxxx, which serves as the vector table, but if you're interrupt-less, your program logic can just start then and there.

• Thanks for the info. If I understood correctly, it means that my main program is actually a "bootloader" by default, unless I burn an actual bootloader to do something else before jumping to main program, is that correct? – Tu Do Jan 11 '15 at 14:33

That's a Cortex M4 ARM Microcontroller from TI. It has a bootloader in ROM. See chapters 1.3.2.3 and 5.2.2.1 of the datasheet: http://www.keil.com/dd/docs/datashts/ti/tm4c123/tm4c123gh6pm.pdf

You can use the ROM bootloader to load your application software or disable the ROM bootloader by writing to the BOOTCFG register. If you override the ROM bootloader, you can specify a reset vector and initial stack pointer value in the flash. You can then put whatever code into the flash, the microcontroller will execute that when it is powered up.

The TivaWare ROM Bootloader and the TivaWare peripheral driver library in ROM may make it easier to write C programs for this particular microcontroller. There seems to be also some getting started demos available, see: http://energia.nu/wordpress/wp-content/uploads/2014/07/Startup_Weekend_Bay_2014_TM4C123_Energia.pdf