What Is Inside a Microcontroller?

A microcontroller (MCU) puts a complete small computer on one chip: a processor core, nonvolatile memory for the program, RAM for data, and a set of peripherals that connect the program to the outside world. Little else is needed to run firmware: a power supply and, depending on the chip, a crystal (many run from an internal oscillator) and, for flashless parts like the RP2040 below, an external program flash. That is the difference from an application processor of the kind in a phone or a Raspberry Pi computer: those use external DRAM measured in gigabytes, a memory-management unit, and an operating system loaded from storage. The line is not sharp, but the design assumption is: an MCU program owns the whole machine, runs from the moment reset ends, and talks to hardware directly through registers.

As a concrete example, take the RP2040. Its published SDK and boot ROM sources describe two Arm Cortex-M0+ cores (NUM_CORES 2), a 16 KiB boot ROM, 264 KiB of on-chip SRAM, and 30 GPIO pins in its main bank. It has no on-chip flash: the program lives in a separate QSPI flash chip that the RP2040 reads through a cached execute-in-place window. Many other microcontrollers put the flash on the same die. Both are microcontrollers; the block diagram is what tells you which one you have.

↑ This step uses the figure at the top of the page.

• Processor core. Fetches instructions from memory and executes them, one after another, using a small set of internal registers (lesson 2). A chip may have one core or several.
• Program memory. Nonvolatile storage for instructions and constant data, almost always NOR flash (lesson 4). A small boot ROM, written by the chip vendor and fixed at manufacture, often runs first.
• Data memory. SRAM for variables, the stack and the heap (lesson 5). It is fast and loses its contents when power is removed.
• Peripherals. Hardware that does one job without the core’s help once configured: GPIO, timers, UART, SPI and I²C controllers, ADCs, PWM generators, USB. Each appears to software as a block of registers at fixed addresses, exactly as unit 2 lesson 5 described.
• Interconnect. The buses and bus matrix that carry every address from whoever starts a transfer to whichever block owns that address (lesson 3).
• Clock and reset. Oscillators, PLLs and dividers that generate the clocks every block runs on, and the logic that puts everything into a known state at power-up and on demand (lesson 6).
• Debug. A port (SWD or JTAG) through which an external probe can halt the core, inspect it and program the flash (unit 6).
• Power management. Voltage regulators, brown-out detection and low-power modes (unit 14).

Step through the figure’s activities and notice how few blocks any single action touches. Reading a variable uses the core, the matrix and SRAM. The other blocks are there so that the core does not have to do everything itself: a UART shifts bits out at the right rate while the core does something else, and DMA can copy the received bytes to memory without executing a single instruction.

Every transfer on the interconnect has an initiator and a responder. A bus master starts a transfer by putting an address and a direction on the bus. A bus slave recognises its own addresses and responds, returning data for a read or accepting it for a write. Memories and peripheral register blocks are slaves. The masters in a typical MCU are:

1. the processor core (or each core),
2. the DMA controller,
3. the debug access port.

On many Cortex-M chips, the RP2040 among them, debug accesses actually leave through the core’s own bus port rather than as a separate master on the matrix (lesson 3 lists the RP2040’s four crossbar masters), but logically the debugger is still something other than your program reading and writing memory.

That list has a consequence that unit 2 already hinted at: the core is not the only thing that changes memory. A DMA transfer can fill a buffer while the program is running, and a debugger can write a variable while the core is halted. Both are reasons the compiler must be told, with volatile or proper synchronisation, when a value can change outside the code it can see.

A sensor logger on an RP2040 has 180 KiB of program code, a 40 KiB constant calibration table, and 12 KiB of working buffers. It must record one 8-byte sample per second for as long as possible. Where does each piece live, and how long can it log?

Code and the table are constant, so they belong in flash, not SRAM. The SDK’s default linker script assumes 2 MiB of flash at 0x1000_0000.

Buffers are written constantly, so they go in SRAM: 12 KiB of the 264 KiB.

The samples. One day is $86\,400 \times 8 = 691\,200$ bytes, 675 KiB. That is more than all the SRAM on the chip, and SRAM would lose it at power-off anyway. The samples must go to flash. Addressing 675 KiB would take $\lceil \log_2 691\,200 \rceil = 20$ bits of offset.

How much flash is left: $2048 - 180 - 40 = 1828$ KiB $= 1\,871\,872$ bytes, room for $1\,871\,872 / 8 = 233\,984$ samples, or about 2.7 days at one per second.

The arithmetic is easy; the decision it forces is the real lesson. Knowing which block holds what, and how big each one is, changes the design before a line of code is written. Lesson 4 adds the catch: flash cannot simply be written like RAM, so logging to it needs care.