Microcontrollers, SoCs, and Development Boards Questions

Clarify requirements
I'm explaining differences and the reset-to-main startup flow for a typical Cortex-M microcontroller, plus safe bootloader update strategies (OTA/flash).

Bootloader vs Application firmware

• Bootloader: small, trusted code in protected flash region. Responsibilities: hardware init (clocks, minimal RAM), verify/choose firmware image, perform recovery/DFU, possibly cryptographic verification, and finally jump to application.
• Application firmware: the main product code, larger, relocated by linker, assumes C runtime initialized and peripherals configured or reset as documented.

Startup steps (reset → main)

1. Reset handler invoked from vector table (first entries: initial SP, reset handler address).
2. Optionally bootloader runs first (if present): minimal init, decide image, verify.
3. If jumping to app: set VTOR to application's vector table base (SCB->VTOR on Cortex-M).
4. C runtime init:
   • Copy .data from flash to RAM using linker symbols (e.g., _etext, _sdata, _edata).
   • Zero .bss (from _sbss to _ebss).
   • Call constructors (for C++).
5. Optionally enable interrupts, then call main().

Safe update patterns

• Atomic/dual-bank (A/B) images: keep two slots; write new image to inactive slot, verify, then flip boot flag to active.
• Verification: checksum (CRC32) for integrity; digital signature (RSA/ECDSA) or HMAC for authenticity. Store metadata header with version, length, checksum/signature.
• Fallback: maintain state machine (VALID, PENDING, INVALID). After update, boot into new image in PENDING; watcher/healthcheck must mark VALID. If boot fails or watchdog resets before VALID, bootloader reverts to previous image.
• Power-loss safety: write metadata/status last; use flash atomic write patterns or wear-leveling.
• Further hardening: secure boot with root of trust in immutable ROM, measurability (rollback protection with monotonic counter), encrypted images.

Implementation notes

• Linker script must place vector table and .data/.bss symbols correctly and provide stack size.
• When jumping, always disable interrupts, set MSP from app vector[0], and branch to app reset handler.
• Keep bootloader minimal, protect its flash region and keys.

Purpose of volatile (brief)

volatile tells the compiler a variable's value can change outside normal program flow (hardware registers, ISRs, DMA). The compiler must not optimize away reads/writes or cache the value in a register — each access generates an actual memory read/write.

Typical bugs if omitted

• Loop waiting for a flag optimized away:
  • while (!flag) { } // compiler may cache flag and loop forever
• Reads from memory-mapped register optimized to one read, missing changes from hardware
• Writes to control registers reordered or removed if the compiler thinks they are dead stores

When volatile is insufficient

• Volatile does not provide atomicity: concurrent updates (read-modify-write) need mutexes or C11 atomics.
• Volatile does not enforce ordering across threads/cores or prevent CPU/hardware reordering — use memory barriers, atomic_thread_fence, or platform-specific barriers.
• For ISR synchronization, volatile plus proper interrupt-enable/disable or atomic ops is required to avoid race conditions.

Practical guidance

• Use volatile for MMIO and simple ISR flags.
• Use stdatomic.h (C11) or compiler intrinsics and memory barriers for multicore, ordering, and atomicity.

Approach

• Use volatile pointers to memory-mapped registers.
• Use bit masks for pin 3 (bit 3).
• Do a read-modify-write for DIR and PULLUP to avoid altering other pins.
• Return logical 0/1 from GPIO_IN masked and shifted.

#include <stdint.h>

#define GPIO_DIR_ADDR     ((volatile uint32_t *)0x40000000)
#define GPIO_PULLUP_ADDR  ((volatile uint32_t *)0x40000004)
#define GPIO_IN_ADDR      ((volatile uint32_t *)0x40000008)

#define PIN3_MASK         (1U << 3)

/* Configure pin 3 as input with pull-up enabled and return its value (0 or 1) */
static inline int read_pin3_with_pullup(void)
{
    /* Set as input: clear bit in DIR (1 = output, 0 = input) */
    uint32_t dir = *GPIO_DIR_ADDR;
    dir &= ~PIN3_MASK;
    *GPIO_DIR_ADDR = dir;

    /* Enable pull-up: set bit in PULLUP register */
    uint32_t pu = *GPIO_PULLUP_ADDR;
    pu |= PIN3_MASK;
    *GPIO_PULLUP_ADDR = pu;

    /* Read pin value, return 0 or 1 */
    return ( ( *GPIO_IN_ADDR & PIN3_MASK ) ? 1 : 0 );
}

Why volatile and RMW

• volatile prevents compiler optimizations that could cache register values or reorder accesses; required for hardware registers.
• Read-modify-write preserves other pins' configuration.
• Using explicit masks keeps code clear and safe for concurrent peripheral usage.

Classic 5‑stage pipeline (brief)

• Fetch (IF): Read instruction from PC into instruction register.
• Decode (ID): Parse opcode, read register operands, sign‑extend immediates.
• Execute (EX): ALU operations, address calculation, branch comparison.
• Memory (MEM): Read/write data memory for load/store instructions.
• Write‑Back (WB): Write result back into register file.

How pipelining improves throughput

• Pipelining overlaps stages of successive instructions so one completes each cycle after pipeline fills. Throughput increases ~N times (N = stages) for steady streams; latency per instruction unchanged but overall instructions/sec rises. In embedded systems this boosts ISR and loop performance with low hardware cost.

Three hazard categories with embedded examples

• Data hazards: When an instruction needs a result not yet written. Example: ADD r1, r2, r3 followed immediately by SUB r4, r1, r5 — SUB reads r1 before ADD’s WB. Fixes: forwarding/ bypassing or stalls.

• Control hazards: Caused by branches changing PC. Example: conditional branch in ISR dispatch; next instruction fetch may be wrong. Fixes: branch prediction, delayed branch, or pipeline flush.

• Structural hazards: Hardware resource conflict. Example: single memory port used for instruction fetch and data load in same cycle on small microcontroller. Fixes: replicate resources, stall, or interleave.

These are practical concerns when optimizing firmware and selecting microcontroller cores or enabling forwarding/stall behavior in low‑level code.

Overview — exception stacking

• On exception entry the processor automatically pushes this basic stack frame (stack grows full-descending): R0, R1, R2, R3, R12, LR (R14), PC (R15), xPSR.
• If the FPU is enabled and hardware (lazy) stacking is used, additional S-registers and FPSCR may be stacked automatically (implementation-dependent: either S0–S15 or upper/lower bank depending on FP lazy state and architecture).

MSP vs PSP

• MSP (Main Stack Pointer) is the default stack for exceptions/handler mode and for reset.
• PSP (Process Stack Pointer) is intended for thread mode (user tasks). Typical RTOS: switch thread stack to PSP and keep MSP for exceptions and context-switching handlers (PendSV/SVC).

PRIMASK and BASEPRI

• PRIMASK = 1 disables all maskable interrupts (all except Non-Maskable and HardFault). Simple global disable.
• BASEPRI holds a priority threshold: interrupts with numerical priority value >= BASEPRI are masked; lower numerical (higher urgency) interrupts still get through. Use BASEPRI to disable a range of priorities without affecting higher-priority ISRs.

Implementing a preemptive context switch (typical PendSV approach)

1. Trigger: set PendSV pending (low priority handler) from SysTick/ISR when scheduler decides to switch.
2. In PendSV handler (assembly preferred):
   • Use MSP (handler mode) so exception stacking handled by hardware; but the thread context is on PSP.
   • Save callee-saved registers R4–R11 onto the task stack pointed by PSP (store multiple). Example sequence: MRS r0, PSP; STMDB r0!, {r4-r11}; write PSP back to TCB.
   • If FPU may be used by task: either enable lazy stacking (FPCCR ASPEN/LSPEN) so hardware saves S0–S15 on exception entry, or proactively save S16–S31 and FPSCR to the stack if full-context required. If using lazy stacking, check EXC_RETURN bit pattern to detect and handle FP stack frame when restoring.
   • Update current task’s stack pointer in its TCB, pick next task, load its PSP from its TCB.
   • Restore registers: LDMIA PSP!, {r4-r11}; if FP state present restore S regs and FPSCR.
   • Write new PSP, exit handler using BX to EXC_RETURN to return to thread mode with PSP.

Notes & trade-offs

• Use PendSV at lowest priority to avoid preemption of the context switch itself.
• PRIMASK can be used to make the short critical sections in scheduler non-preemptible; use BASEPRI to allow high-priority interrupts to remain active.
• FPU handling: lazy stacking reduces overhead when most tasks don’t use FPU; explicit save/restore is needed if deterministic timing or when using custom FP register banks.

This approach balances hardware stacking (R0–R3,R12,LR,PC,xPSR) with software-saved callee-saves and selective FP handling to implement an efficient, preemptive RTOS context switch on Cortex-M.