面试踩坑实录：自称精通 STM32+FreeRTOS，基础题直接露怯

Industry Exchange Job Search & Career Community
,
1

Today I interviewed a candidate whose resume claimed “expertise in STM32 development and FreeRTOS applications.” I thought they’d be a perfect match, but after a few basic embedded systems questions, their true skill level was exposed. I’ve compiled the core Q&A with professional analysis here - both to help professionals avoid pitfalls and remind newcomers: without solid fundamentals, even the most impressive resume is meaningless.

I. Fatal Q&A Transcript (With Professional Analysis)

1. Q: What’s the core difference between const and volatile in embedded systems?

A: const can’t be modified, volatile can be modified…

:cross_mark: Only surface-level understanding
:white_check_mark: Professional Analysis:

  • const guarantees immutability at the compiler level, used to restrict constants/readonly variables and prevent accidental writes
  • volatile tells the compiler to disable optimizations, preventing variables from being incorrectly optimized away when they might change unexpectedly. Key use cases:
  1. Hardware register access (e.g., volatile uint32_t *reg = (uint32_t*)0x40000000; - register values can be modified by hardware)
  2. Multithreaded/task-shared variables (prevents inter-thread synchronization issues)
  3. Global variables shared between ISR and main program
    Bonus: const volatile uint32_t *reg represents hardware read-only registers (hardware writes, software reads - prevents software modification and compiler optimization)

2. Q: Why shouldn’t printf be called in an ISR?

A: Because printing is too slow…

:cross_mark: Only addresses superficial symptoms
:white_check_mark: Complete Explanation:
Calling printf in ISR creates 3 critical issues beyond simple performance concerns:

  1. May trigger non-reentrant dynamic memory operations (malloc/free) causing memory corruption between ISR and main thread
  2. Contains system calls that might trigger context switches, breaking ISR atomicity
  3. Uncontrolled execution time violates real-time requirements and could block higher-priority interrupts
    Practical Alternatives:
  • Circular buffer logging (ISR writes to buffer, main loop handles printing)
  • Flag-based triggering (main program detects flag and executes output)
  • Lightweight logging components (avoid dynamic memory)

3. Q: How to safely read/write 32-bit variables between ISR and main program?

A: Use a mutex lock?

:cross_mark: Critical Misconception: Mutex in ISR risks deadlock, FreeRTOS mutexes aren’t ISR-safe by default
:white_check_mark: Standard Practices:

  1. Disable Interrupts: __disable_irq() → read/write → __enable_irq() (simple but control critical section duration)
  2. Atomic Operations: ARM builtins __atomic_load_32()/__atomic_store_32() for hardware-enforced single-cycle access
  3. Byte Splitting: Split 32-bit into 4×8-bit variables (for 8/16-bit cores, optional for 32-bit)
  4. Hardware Instructions: Cortex-M LDREX/STREX for exclusive access (prevents race conditions)
    :warning: Note: Unaligned 32-bit access on ARM can trigger HardFault - must ensure proper alignment

4. Q: How to handle DMA vs interrupt priority?

A: DMA should have higher priority?

:cross_mark: Oversimplifies three-layer priority mechanism
:white_check_mark: In-depth Analysis:
Embedded priorities require coordinating 3 layers:

  1. Hardware Priority: NVIC controller config (IRQn priority, lower numerical value = higher)
  2. Software Priority: RTOS task/interrupt priorities (FreeRTOS vTaskPrioritySet)
  3. Data Flow Priority: STM32’s DMA_CCRx register configures per-channel data flow priorities
    Classic Case:
    ADC sampling with DMA double-buffering requires DMA interrupt priority > ADC interrupt priority - prevents data loss when ADC completes sampling before buffer switch

II. Interview Lessons (For Newcomers, HR, and Interviewers)

1. Resume Minefields (Avoid These!)

  • “Expert” Claims:

    • “STM32 expert”? Expect questions about SPI CRC implementation, I2C NACK handling, timer dead-time configuration
    • “FreeRTOS expert”? Prepare for task scheduling mechanics, semaphore vs mutex differences, stack overflow detection

  • Vague Project Descriptions:
    Don’t just say “developed XXX driver” - provide concrete examples:
    “Debugged I2C bus race condition using logic analyzer, resolved with mutex + timeout retry”

  • Skill Matching Reality:
    Using HAL libraries ≠ expertise. Actual requirements: writing low-level drivers independently, debugging hardware-software integration issues

2. Embedded “Death Questions” (Fail = Interview Over)

  1. Draw the complete interrupt handling flowchart from your project (including context saving/restoring and nesting)
  2. How to verify your driver is free from race conditions/deadlocks? (Show practical methods like logic analyzer traces, task stack analysis)
  3. Describe the hardest hardware bug you encountered - troubleshooting process and resolution methodology
  4. FreeRTOS task switching mechanics? What’s the role of Cortex-M’s PendSV interrupt?
  5. STM32 GPIO configuration considerations for alternate functions (pull-up/down resistors, output speed, AF mapping)

III. Community Discussion

Have you encountered other cases where candidates’ resumes didn’t match their actual skills? Or want to share essential embedded interview questions? Let’s discuss in the comments! Newcomers should focus on fundamentals rather than blindly claiming “expertise” - solid technical foundations are what truly matter.