Top 20 Embedded C Interview Questions

The textbook answer is that volatile tells the compiler a variable can change outside the program’s flow. The real-world implications are far more severe:

1. DMA Data Transfers: A common failure scenario is using a buffer for DMA (e.g., to send data over SPI). The CPU sets up the DMA and then checks a variable or the buffer itself to see if the transfer is complete.

   c

   // DANGEROUS CODE - Missing volatile
   uint8_t dma_tx_complete = 0;
   uint8_t tx_buffer[100];
   
   // Start DMA transfer
   HAL_DMA_Start(&hdma_spi, tx_buffer, &SPI1->DR, 100);
   // ... wait for completion
   while(!dma_tx_complete) { /* Wait */ } // Compiler might optimize this into an infinite loop!

   The compiler sees dma_tx_complete as never being set inside the while loop and could optimize the check away. The ISR that the DMA triggers to set dma_tx_complete is invisible to the compiler. The same logic applies to the tx_buffer itself if the DMA is reading from it; the compiler might use a pre-fetched, stale copy from a register.

2. Memory-Mapped Registers (MMRs): This is the most critical use case. All hardware registers must be declared volatile. Writing to a register is a side-effect the compiler must not reorder or eliminate.

   c

   #define GPIOA_ODR (*(volatile uint32_t*)0x48000014)
   
   void set_led(void) {
       GPIOA_ODR |= (1 << 5);  // Set PA5
       // Without volatile, the compiler might see two writes to the same address
       // and remove the first one as a "redundant store."
       GPIOA_ODR |= (1 << 5);  // "Redundant" write? Not for the hardware!
   }

3. Multi-threaded/RTOs Environments: When a shared flag is modified by a task and read by another, the compiler might cache the flag’s value in a register. volatile ensures the read always comes from the actual memory location. (Note: volatile alone is not sufficient for atomicity; it must often be paired with other mechanisms like critical sections or atomic types).

Conclusion: Missing volatile doesn’t cause a compilation error; it causes a miscompilation that behaves correctly in debug mode but fails unpredictably in release mode with higher optimization levels, making it a “Heisenbug.”

Fragmentation is the headline issue, but the problems run much deeper, affecting determinism, reliability, and verifiability.

1. Non-Determinism: The time it takes for malloc() or free() to execute is not constant. It depends on the current state of the heap (the number and size of previously allocated/freed blocks). This violates the fundamental principle of real-time systems, which require bounded, predictable worst-case execution times (WCET).

2. Memory Fragmentation: Over time, allocating and freeing blocks of different sizes leaves small, unusable gaps of free memory between allocated blocks. A request for a large, contiguous block can fail even if the total free memory is theoretically sufficient. This leads to system failure after an unpredictable period of operation.

3. Heap Overflow and Corruption: There is no inherent way for malloc to know the boundaries of your available RAM. An allocation request can succeed but return a pointer that extends beyond the defined heap region, corrupting other data structures (e.g., stack, BSS) and leading to catastrophic failure.

4. Memory Exhaustion: There is no standard way for malloc to recover from being out of memory. You must check its return value for NULL on every call, which is often forgotten. In a system with no OS, what do you do if malloc fails? It’s often an unrecoverable error.

The Safe Alternative: Use static allocation. All memory is allocated at compile-time or startup.

// Instead of: UART_Buffer* buf = malloc(sizeof(UART_Buffer) * 32);

// Do this:
#define MAX_UART_BUFFERS 32
static UART_Buffer uart_pool[MAX_UART_BUFFERS];
static uint8_t uart_pool_used[MAX_UART_BUFFERS] = {0};

UART_Buffer* acquire_uart_buffer(void) {
    // ... find a free index in uart_pool_used and return &uart_pool[i]
}
// This is deterministic, avoids fragmentation, and memory usage is known at link time.

ISRs are the “sharpest tools” in the shed. Misuse leads to timing-sensitive bugs.

1. Keep it Short (“The Deferred Processing Model”): An ISR should do the absolute minimum: typically, capturing hardware status (e.g., reading a UART RX data register), clearing the interrupt flag, and then triggering a mechanism for the main loop or a task to do the heavy processing (parsing, computation). This minimizes interrupt latency for other, potentially higher-priority interrupts.

2. Avoid Non-Reentrant Functions: Never call library functions like printf, malloc, or sprintf from an ISR. These functions are often not reentrant and can corrupt their internal state if interrupted themselves. Use simple, custom functions that only work on local variables or dedicated buffers.

3. Shared Data Protection: Any variable shared between an ISR and the main context (or another task) is a critical section.

   c

   volatile uint32_t systick_count = 0;
   
   void SysTick_Handler(void) { // ISR
       systick_count++; // This is a read-modify-write operation!
   }
   
   uint32_t get_current_count(void) {
       // In main context
       return systick_count; // What if this read is 64-bit and is interrupted?
   }

   On a 32-bit system, a 64-bit variable would require multiple instructions to read/write. The ISR could fire in the middle, leading to a corrupted value. The solution is to use atomic operations, disable interrupts during the access in the main context, or use RTOS primitives like semaphores (though semaphores in ISRs have their own rules).

4. Correct Interrupt Configuration: Forgetting to set the interrupt priority (NVIC in ARM) or forgetting to clear the interrupt pending flag inside the ISR will cause the system to immediately re-enter the same ISR in an infinite loop, crashing the system.

 Packing eliminates padding bytes, saving RAM at the cost of performance and potential hardware faults.

• Why Padding Exists: CPUs access memory most efficiently at naturally aligned addresses (a 32-bit int is best accessed at an address divisible by 4). The compiler inserts padding to ensure each member is correctly aligned.

  c

  // Without packing (assuming 32-bit int)
  struct sensor_data {
      uint8_t id;      // 1 byte
      // 3 bytes of padding
      uint32_t value;  // 4 bytes
  }; // sizeof(struct sensor_data) = 8 bytes
  
  // With packing
  struct __attribute__((packed)) sensor_data {
      uint8_t id;      // 1 byte
      uint32_t value;  // 4 bytes
  }; // sizeof(...) = 5 bytes

• The Performance Cost: Accessing an unaligned member like value in the packed struct forces the CPU to generate multiple, slower memory accesses and stitch the data together in software. On some architectures (older ARMs), unaligned accesses resulted in a hard fault and crashed the system. Modern Cortex-M cores support them but at a significant performance penalty.

• When to Pack:

  • Memory-Constrained Devices: When every byte counts (e.g., a simple 8-bit AVR).

  • Protocols and Packets: When a structure must map exactly to a communication packet (e.g., a CAN message, a UDP header) to be sent byte-for-byte over a wire.

• The Best Practice: Manually order your structure members from largest to smallest to minimize padding waste naturally.

  c

  struct efficient {
      uint32_t value;  // 4 bytes
      uint16_t range;  // 2 bytes
      uint8_t id;      // 1 byte
      // 1 byte padding (if in an array, to align the next struct's 'value')
  }; // sizeof(...) = 8 bytes (better than the original 12 it might have been)

restrict is a promise to the compiler that for the lifetime of the pointer, only that pointer (or expressions based on it) will be used to access the object it points to. It indicates no aliasing, allowing for aggressive optimization.

Example: Memory Copy Function

// Without restrict
void my_memcpy(uint8_t* dst, const uint8_t* src, size_t n) {
    for (size_t i = 0; i < n; i++) {
        dst[i] = src[i]; // Compiler MUST re-load src[i] every time because
                         // dst and src could overlap! What if dst == src + 1?
    }
}

// With restrict
void my_memcpy(uint8_t* restrict dst, const uint8_t* restrict src, size_t n) {
    for (size_t i = 0; i < n; i++) {
        dst[i] = src[i]; // Compiler can now assume dst and src do NOT overlap.
                         // It can load multiple src[i] into registers and
                         // perform a much faster, vectorized copy.
    }
}

In DSP applications on Cortex-M4/M7 with SIMD instructions (like ARM’s NEON), using restrict on arrays being processed by filters (e.g., FIR) is often the difference between the compiler generating a slow single-instruction loop and a highly parallelized, fast one. It tells the compiler it’s safe to pre-fetch data and reorder instructions.

const is not just a safety feature; it’s a directive to the linker.

1. RAM vs Flash Placement:

   c

   const char welcome_msg[] = "Hello World"; // Placed in Flash (.rodata section)
   char debug_buffer[128];                   // Placed in RAM (.data or .bss section)

   The const qualified object is placed in the .rodata (read-only data) section, which the linker script maps to the non-volatile Flash memory. This saves precious RAM.

2. Linker Script’s Role: The linker script (e.g., STM32F4xx.ld) contains a MEMORY command defining the regions (FLASH, RAM) and their addresses/sizes. The SECTIONS command then maps input sections (like .text, .rodata) to these memory regions. By declaring a variable const, you ensure the compiler puts it in an input section that the linker will place in Flash.

3. Robustness: Attempting to write to a const variable (e.g., welcome_msg[0] = 'h';) will result in a compile-time warning and, more importantly, a run-time fault on most embedded systems because the CPU’s memory protection unit (MPU) or the memory controller itself will generate a write error to the Flash address, catching a critical bug.

Attributes give the programmer low-level control typically reserved for the compiler.

1. section(".section_name"): Forces a function or variable into a custom linker section.

   • Use Case 1 (CCM RAM): On STM32F4, CCM RAM is tightly coupled to the CPU for fastest access, but can’t be accessed by DMA.

   c

   void __attribute__((section(".ccmram"))) critical_isr_helper(void) {
       // This function's code will be placed in CCMRAM for fastest execution.
   }

   • Use Case 2 (Non-Volatile Memory): Storing a configuration struct in a separate, non-default Flash sector to emulate EEPROM.

   c

   const __attribute__((section(".eeprom"))) device_config_t cfg;

2. interrupt or IRQ: Tells the compiler the function is an ISR. The compiler will then generate prologue and epilogue code that correctly saves/restores registers and uses the appropriate return instruction (e.g., BX LR vs BX LR with exception return).

3. naked: Removes all prologue/epilogue code. The programmer writes pure assembly in the function. Used for the absolute lowest-level operations, like the very first bootloader instruction or context switching in an RTOS.

   c

   void __attribute__((naked)) Reset_Handler(void) {
       __asm("ldr sp, =_estack");
       __asm("b main");
   }

4. weak: Creates a weak symbol. This is fundamental for library design and overriding default handlers. The chip vendor’s startup file defines __attribute__((weak)) void TIM2_IRQHandler(void) {}. If you define your own TIM2_IRQHandler in your code, the linker will use your strong definition, overriding the weak one. If you don’t, the weak (often empty) one is used.

A “hard fault” exception occurs, and you suspect a stack overflow. Describe a systematic methodology to diagnose and confirm this, using both toolchain-assisted and manual techniques.

A: Stack overflows are a common source of crashes. Here’s a systematic approach:

1. Linker Map File Analysis: The first step is to understand the memory layout. After building, inspect the linker map file (.map).

   • Find the address of _estack (initial stack pointer, usually top of RAM).

   • Find the address and size of the .stack section (or similar, defined in the linker script).

   • Locate the .data and .bss sections. The stack grows down from _estack, while .data/.bss grow up. An overflow occurs when they collide.

2. Toolchain-Assisted (GCC -fstack-usage): Compile with the -fstack-usage flag. This generates a .su file for each .c file, showing the worst-case stack usage of every function. This static analysis helps identify stack-hungry functions.

3. Runtime Monitoring with Canaries:

   • Method: At startup, fill the entire stack space with a known pattern (e.g., 0xDEADBEEF).

   • Diagnosis: When a crash occurs, halt the debugger and inspect the memory region reserved for the stack. The point where the pattern is no longer 0xDEADBEEF indicates how far the stack has grown. If the pattern is corrupted far into the area, it’s a strong sign of overflow.

4. Debugger (IDE) Watchpoints: Some debuggers allow you to set a data watchpoint on a specific memory address, like the last byte of the stack region or a specific variable at the end of the .bss section. When this address is written to, the CPU halts, catching the overflow red-handed.

5. RTOS-Specific Tools: Modern RTOSes like FreeRTOS have built-in hooks (uxTaskGetStackHighWaterMark) that tell you the minimum amount of free stack space that has ever existed during runtime, helping you to size your stacks correctly.

This is a critical distinction for RTOS and ISR programming.

• Reentrant: A function can be interrupted and re-entered (called again) before the previous invocation has finished, without affecting the outcome. This typically requires the function to use only stack variables and parameters, and to call only other reentrant functions.

• Thread-Safe: A function can be called safely from multiple threads (tasks) concurrently. This can be achieved through synchronization mechanisms like mutexes or semaphores, even if the function itself is not reentrant.

The Local Static Buffer Problem:

// NON-REENTRANT FUNCTION
char* get_timestamp(void) {
    static char buffer[20]; // Memory is in static RAM, not on the stack.
    sprintf(buffer, "%lu", HAL_GetTick());
    return buffer;
}

If get_timestamp() is called from main() and then interrupted by an ISR that also calls get_timestamp(), the ISR call will overwrite the buffer that the main() task was using. Both invocations now use the same memory for buffer.

Fixing It:

1. Make it Reentrant (Best): Pass the buffer as an argument.

   c

   void get_timestamp(char* buffer, size_t len) {
       snprintf(buffer, len, "%lu", HAL_GetTick());
   } // This function is now reentrant and thread-safe (if the libc's snprintf is).

2. Make it Thread-Safe (if not reentrant): Use a mutex to protect the non-reentrant function. This prevents other threads from entering it concurrently, but it does not make it safe to call from an ISR (as ISRs cannot block on mutexes).

The choice is a trade-off between complexity, responsiveness, and resource usage.

Choose a Super Loop when:

• Low Complexity: The system has a small number of simple, sequential tasks (e.g., read sensor, update display, sleep).

• Hard Real-Time not Required: While tasks must be timely, the deadlines are not so tight that a long-running task (like a complex display update) would cause a critical failure.

• Extreme Cost Sensitivity: The MCU has very limited RAM/Flash (e.g., < 32KB Flash, < 4KB RAM). An RTOS has a memory overhead for kernel data structures and multiple stacks.

• Deterministic Power Management: It’s easier to put the entire system into a low-power sleep mode in a single, coordinated place in the loop.

Choose an RTOS when:

• Complex Scheduling: You have multiple tasks with different priorities and timing requirements. A high-priority task (e.g., motor control) must preempt a low-priority task (e.g., logging) immediately.

• Blocking Operations: A task needs to wait for an event (a semaphore from an ISR, a message from another task, a timer to expire) without “busy-waiting,” allowing lower-priority tasks to run.

• Software Modularity: The system is complex and benefits from being decomposed into separate, well-defined tasks that communicate through clean APIs (queues, semaphores). This improves maintainability.

• Concurrency: You need to manage multiple peripherals (Ethernet, USB, UART) that all operate concurrently and asynchronously.

**The “Super Loop with Interrupts” is a valid middle ground, where time-critical events are handled in ISRs, which set flags for the main loop to process, but the scheduling in the main loop remains cooperative rather than preemptive.