Microcontrollers, SoCs, and Development Boards Questions

Selecting and reasoning about microcontroller and system-on-chip families, evaluation boards, and reference platforms for embedded work. Covers CPU cores, memory maps, on-chip peripherals, boot flow, and the trade-offs between MCU, MPU, and SoC targets. Includes how architecture choices constrain firmware and toolchain decisions.

EasyTechnical

89 practiced

Explain the role of the system clock and clock gating in a microcontroller. Discuss how clock prescalers affect peripheral timing (for example UART baud rate calculation), and how enabling/disabling clocks to peripherals can be used as a power optimization.

Sample Answer

**Role of the system clock & clock gating**

The system clock provides the timing reference for the CPU core and buses. All synchronous logic, timers, and peripheral state machines derive their timing from clock domains. Clock gating selectively stops the clock to specific blocks (peripheral or sub-module) so flip-flops stop toggling, reducing dynamic power while preserving state if designed for gated clock use.

**Clock prescalers and peripheral timing (UART example)**

Prescalers divide a higher-frequency clock to generate lower-rate clocks for peripherals. For UART, baud is derived from the peripheral clock and its divisor. Typical formula:

text

baud = peripheral_clock / (16 * UBRR)   // for 16x oversampling UART

Plain English: increasing the prescaler (reducing peripheral_clock) lowers achievable baud or requires changing UBRR. Example: 48 MHz system clock with APB prescaler /2 => peripheral_clock = 24 MHz. To get 115200 baud:

text

UBRR ≈ 24_000_000 / (16 * 115200) ≈ 13

Careful: integer rounding causes baud error — check percent error vs spec.

**Power optimization via enabling/disabling clocks**

Enable clocks only when peripheral is used; disable otherwise. This eliminates dynamic switching in that block. Practical tips:- Use clock gating APIs in HAL or directly write peripheral clock enable bits in RCC.- For low-power modes, gate clocks and put unused peripherals into reset to avoid leakage/state corruption.- Combine with disabling NVIC interrupts for idle peripherals and gating bus clocks to reduce bus activity.

I would demonstrate this in firmware by enabling UART clock before init, disabling when idle, and measuring mA reduction in power profiler.

EasyTechnical

80 practiced

Compare microcontrollers and application-class processors (for example an ARM Cortex-M MCU vs an ARM Cortex-A application processor). Explain differences in features like MMU vs MPU, caches, privilege model, typical OS support, performance, power characteristics, and typical peripherals integration.

HardTechnical

85 practiced

Compare interrupt-driven, polled, and DMA-based acquisition strategies for multiple high-rate sensors (example: 4 sensors at 10 kHz each). Propose a hybrid architecture that meets timing constraints, calculate required DMA channels and buffer sizes for a chosen latency target, and estimate CPU cycles consumed per second for interrupt processing versus DMA handling.

Sample Answer

**Clarify requirements & assumptions**- 4 sensors @ 10 kHz each → 40,000 samples/s total.- Sample size: 16-bit (2 bytes). Latency target: 5 ms from sample to CPU processing.- MCU has DMA controller with at least 4 channels, supports circular mode and half/full buffer interrupts.

**Strategy comparison (short)**- Polling: Simple but must sample 40k/s in software → tight timing, wastes CPU, jitter-prone.- Interrupt-driven (per-sample IRQ): Low latency per sample but 40k IRQs/s → high interrupt overhead, poor scalability.- DMA-based: Offloads transfers to hardware, CPU interrupted only on buffer events → very low CPU cost, deterministic bus usage.

**Proposed hybrid architecture**- Each sensor wired to its own ADC/DMA channel. Configure DMA in circular, ping-pong (double) buffer per sensor.- Timer triggers ADC conversions at 10 kHz for each sensor (or synchronized multiplexed ADC with DMA scatter/gather if single ADC).- DMA generates interrupt on half/full buffer (choose half to reduce worst-case latency).- CPU processes buffer in ISR or schedules RT task; processing must complete within buffer-interval (<= 5 ms).

**Calculations**- Samples per sensor per 5 ms = 10,000 sps * 0.005 s = 50 samples.- Choose 64-sample buffers (power of two). Bytes per buffer per sensor = 64 * 2 = 128 B.- Double-buffer per sensor = 256 B. Total RAM for 4 sensors = 4 * 256 = 1024 B (1 KiB).- DMA channels required: ideally 4 channels (one per sensor) for independent circular transfers. If single ADC multiplexed, 1 DMA channel + scatter/gather or memory layout to separate sensors.

**Interrupt rate & CPU cycles**- Per-sample interrupts approach: - IRQs/s = 40,000. - Assume ISR overhead ~1,000 CPU cycles (enter, read sample, store, exit) → 40,000 * 1,000 = 40,000,000 cycles/s. - On a 120 MHz MCU this is ~33% CPU just for IRQ overhead (no processing).- DMA half-buffer interrupts with 64-sample half => interrupts per sensor = 10,000 / 32 = 312.5 -> choose 312 or 313. - Total IRQs/s ≈ 4 * 312.5 = 1,250 interrupts/s. - ISR overhead for buffer-ready: assume 1,000 cycles (or less because copying small block/process scheduling) → 1,250 * 1,000 = 1,250,000 cycles/s (~1.04% of 120 MHz). - If ISR is slimmer (500 cycles) => ~625k cycles/s.- DMA controller bus cycles for transfers are off-CPU; negligible CPU cycles except setup: initial DMA config maybe few thousand cycles at boot and occasional reconfig.

**Trade-offs & notes**- Per-sample IRQ gives minimal per-sample latency but unsustainable CPU load.- DMA + half/full buffer meets 5 ms latency (50-sample window) — using half-buffer gives ~1.6 ms worst-case latency (half of 64 samples).- If lower latency needed (<1 ms), reduce buffer to 16–32 samples (increase IRQ rate) and re-evaluate CPU budget.- If MCU has fewer DMA channels, use one channel with scatter-gather or time-multiplexed ADC and ensure DMA can tag data to sensor buffers.

**Recommendation**Use DMA circular with per-sensor double buffers (64 samples) and half-buffer interrupts. Allocate 1 KiB of RAM for buffers and 4 DMA channels. This keeps CPU load low (~1% of 120 MHz) while meeting 5 ms latency and providing predictable timing for processing.

MediumTechnical

84 practiced

Explain interrupt priorities and nested interrupts on microcontrollers with an advanced interrupt controller (for example NVIC on Cortex-M). How do you configure priorities, enable preemption, and what strategies reduce problems like priority inversion or unexpectedly long ISR latency?

Sample Answer

**Brief answer / context**Interrupt priority in advanced controllers (NVIC on Cortex‑M) is a numerical scheme where lower numeric value = higher urgency. The NVIC uses configurable priority fields (usually top N bits of an 8‑bit priority register) and supports hardware nesting: a higher‑priority interrupt can preempt a lower‑priority ISR.

**How to configure priorities & enable preemption**- Set priority via NVIC_SetPriority(IRQn, priority). Remember only the implemented high bits matter (e.g., 3 bits -> priorities spaced by 1 << (8 - 3)).- Configure group vs subpriority with AIRCR.PRIGROUP if using group/sub split (rare in simple setups).- Preemption is automatic: if an incoming IRQ has a numerically lower priority than the currently executing handler, hardware performs tail‑chaining and stacks context and enters new ISR.- Use BASEPRI to mask interrupts below a threshold without disabling all exceptions. PRIMASK disables all maskable interrupts. FAULTMASK blocks even faults.

**Strategies to reduce priority inversion & long ISR latency**- Keep ISRs short: do minimal work (acknowledge/hw clear) and defer processing to a thread/task or a software queue.- Use priority ceiling / assign higher priority to critical resources or protect shared data with brief critical sections. Prefer BASEPRI to create fine‑grained critical regions rather than disabling all interrupts.- Avoid long blocking inside ISRs (no waits, no heavy loops).- Align priority numbers to implemented bits to avoid unexpected ties.- Avoid mixing priority-sensitive RTOS APIs from very high priority ISRs; document which ISR priorities may call OS services.- Test worst‑case ISR latency with latency injection and measure tail‑chaining and stack usage; increase stack for nested scenarios.

**Practical tips**- Use static asserts to ensure priority constants match implemented bits.- Profile with a logic analyzer / instrumented GPIO toggles to verify preemption and latency.- When sharing data between ISRs and tasks, use lock‑free buffers or disable only the necessary priority range via BASEPRI.

HardSystem Design

68 practiced

You must implement a mixed-criticality system on a single MCU: a safety-critical control loop at 1 kHz and a telemetry stack that bursts data and can be deferred. Propose an architecture guaranteeing real-time control deadlines: interrupt priority scheme, minimal ISR latency for the control loop, use of DMA for telemetry, budget calculations (CPU cycles and worst-case execution time), and strategies to isolate and protect the control loop from telemetry overload.

Sample Answer

**Overview / requirements clarification**- Hard real-time 1 kHz control loop (deadline = 1 ms, jitter minimal).- Telemetry is lower-criticality, bursty, deferrable. Single MCU with DMA and NVIC-like interrupt controller.

**High-level architecture**- Control loop runs from a high-priority timer interrupt (hardware periodic timer).- Telemetry uses DMA + peripheral IRQs at low priority; large transfers occur in background tasks or a low-priority ISR that only kicks a worker.- Use an RTOS or a simple prioritized scheduler; ensure priority inversion avoided using priority ceiling or disabling preemption only for very short critical sections.

**Interrupt priority scheme**- Highest: Control timer ISR (priority 0 / highest). Keep ISR minimal.- Next: Safety-related fault handlers (if separate).- Lowest: Telemetry peripheral IRQs and DMA completion.- Ensure NVIC tail-chaining and preemption configured to minimize latency.

**Minimal ISR design for control loop**- ISR responsibilities: timestamp, read critical sensors (via fast registers or cached DMA buffer), run a deterministic control routine (or schedule a fixed-priority high-priority thread), write actuator outputs, clear timer.- Keep ISR code under a tight WCET (e.g., < 200 µs). If control compute > comfortable ISR budget, ISR should only set a flag/semaphore and wake a realtime task running at highest priority.

**Use of DMA for telemetry**- Configure circular or block DMA to move peripheral samples into RAM without CPU.- DMA IRQs are low priority and only signal the telemetry worker to process/pack data.- Rate-limit telemetry processing using token-bucket or a budgeted background task; drop or compress low-value samples under overload.

**Budget calculations (example)**- Deadline = 1 ms.- Let WCET_control = 150 µs (measured worst-case cycles).- Context switch + IRQ entry/exit overhead = 20 µs.- Safety margin = 30 µs.- Total budget = 150 + 20 + 30 = 200 µs < 1 ms safe.

Include CPU-time conversion:

text

time (s) = cycles / cpu_clock_hz

Plain intuition: convert measured cycles to time to ensure WCET fits.

For utilization (for schedulability checks):

text

U = WCET_control / period = 200e-6 / 1e-3 = 0.2 (20%)

Intuition: Leaves 80% headroom for lower-critical tasks and jitter.

**Isolation & protection strategies**- Priority isolation: telemetry always preempted by control.- Budget enforcement: telemetry task implements a runtime CPU budget (e.g., execute only X ms per second) and yields when exhausted.- Memory protection: place control data structures in separate memory region; if MPU available, mark telemetry buffers non-executable and bounded.- Watchdog + health monitor: watchdog reset or degrade telemetry when control deadlines miss; track missed-deadline count and trigger safe mode.- DMA safeguards: use peripheral/DMA flow-control and circular buffers with watermarks; on buffer overrun, drop oldest telemetry rather than block control.- Testing: measure ISR latencies with logic analyzer; run stress tests with worst-case telemetry bursts and verify zero missed deadlines.

**Trade-offs**- Running full control in ISR reduces latency but increases complexity and risk; using a highest-priority thread keeps stack and timing easier to test.- Aggressive telemetry buffering reduces CPU interrupts but uses RAM.

This design yields deterministic control timing, minimal ISR latency, DMA-offloaded telemetry, and runtime protections to prevent telemetry overload from impacting safety-critical control.

Unlock Full Question Bank

Get access to hundreds of Microcontrollers, SoCs, and Development Boards interview questions and detailed answers.

Join thousands of developers preparing for their dream job.