Booting A Cortex M with NO IDE : like a caveman : Intro

The magic before main ( )

If you are anything like me, you have landed here because you are wondering about all those files  generated by the IDE and how you can edit and  use them to your advantage, or perhaps simply to understand what they are and what their purpose is. 

No matter your reason for being here it is safe to say that understanding those files and how your microcontroller gets to main will only make you a better engineer/student/hobbyist because not every project lends itself to an IDE. 

Imagine a huge project with multiple dependencies and multiple binaries that need to be merged etc…. 

Messing around with all of that in an IDE is actually more trouble then maintaining a Makefile yourself, not to mention IDE and their “updates” can break things and then you are in a place where you have to keep a certain version of something around just for compatibility.

I will only explain the sequence of events that occurs at boot from  a firmware developer’s  perspective, meaning I will not go into detail about voltages and power sequencing.  We will write the necessary files to build a project completely free of an IDE. 

This may not be an exhaustive tutorial on every aspect of linker scripts, Makefiles, startup files but it will be more than enough to get you to main.

Furthermore there are some different things happening in different Cortex cores not to mention different boot modes. For the sake of sanity, clarity and brevity I will discuss the normal boot process of a Cortex M4. 

Just because we will not be using an IDE does not mean we do not require some ready-made tools like compiler, linker, GDB etc… But I will discuss those requirements in the next part. 

Get in loser! We're going coding!!!

ARM Cortex Power Up Sequence

At power-up, the processor loads the Stack Pointer (SP), typically the Main Stack Pointer (MSP), with the value stored at address 0x00000000. This value usually represents the top of your RAM region.

But why the top address? 

The MSP is located at the top of RAM because the stack is a full descending stack that grows down, so to speak.

From the highly advanced image above only available to industry insiders, we can see that the stack mechanism grows down towards the lower address while the heap memory space grows upward. Both of these mechanisms grow dynamically. Note that your application may or may not require heap allocation. But you always need stack space. 

Next, the processor reads the value at address 0x00000004* and loads it into the Program Counter (PC). This value is intentionally set to be the address of the reset handler, which is the entry point of your application after a reset. As a result, the first instruction to be executed is the reset handler, which sets up the necessary environment before smoothly transitioning to the main function.

*The next value is 0x00000004 instead of 0x00000001 because the Cortex-M uses 32-bit addresses which are 4 bytes wide, so incrementing to the "next" address is essentially 4 bytes away

How do these values get there? How do you program those values if the MCU needs to be running for any of your code to even work? Is this a chicken and egg scenario? Two words, my friend: vector table. Here's another two words: linker script. And two more: startup file. These three components are the key pieces we need to write by hand to get to main. Of course, the devil is in the details, and other files are necessary, but we won’t be writing those by hand. These include the device header file with all the register definitions, as well as some CMSIS files relevant to the core registers, provided by ARM. Some of these files are thousands of lines long and are autogenerated by the MCU vendor and ARM. In the next post, we’ll gather the necessary components, such as the compiler, documentation, and those header files from ARM and the MCU vendor. Don’t fret—this may sound complicated, but it’s not. ARM MCUs are relatively easy to get up and running, and we won’t even need to touch assembly if we don’t want to. And we won’t.

NEXT>>