Embedded Engineer interview questions

I would separate the three timing domains and keep hardware ownership explicit.

• A 1 ms acquisition task would wake from a timer or DMA notification, timestamp samples, and enqueue fixed-size records without doing CAN work.
• A 10 ms publisher task would own CAN transmission, while a 100 ms diagnostics task would run below both time-critical tasks.
• I would pass data through bounded queues and give each peripheral one owner, avoiding shared-driver locks in the 1 ms path.
• I would size each stack from measured high-water marks under worst-case load, then leave at least 25% headroom within the 128 KB budget.

I would assign fixed priorities by deadline, with the 2 ms control task highest.

• FreeRTOS runs the ready task with the higher numeric task-priority value, so I might use control 4, telemetry 3, and logging 1.
• I would keep interrupt-deferred work that can unblock control at an appropriate priority without placing routine logging above telemetry.
• Each task would block on a delay, queue, or notification when idle so a lower-priority task can run.
• I would verify response times with measured worst-case execution and blocking, because priority numbers alone do not prove the 2 ms deadline.

I would use vTaskDelayUntil so releases stay anchored to the original 10 ms schedule.

• Initialize a TickType_t lastWake with xTaskGetTickCount before the loop, then call vTaskDelayUntil with pdMS_TO_TICKS(10) on each iteration.
• Unlike vTaskDelay, this avoids accumulating the variable 1 ms to 3 ms execution time into the next release.
• I would timestamp each start and flag an overrun if the previous iteration reaches or passes its next release.
• The tick rate must represent 10 ms exactly enough for the requirement; tighter phase accuracy should use a hardware timer notification.

The calculated WCET utilization is 50%, so the task set passes a sufficient utilization test, but I would accept it only after response-time analysis.

• The utilization is 0.4/2 + 1/5 + 2/20 = 0.50 using worst-case execution times, not measured average CPU load.
• Under rate-monotonic priorities, the sufficient Liu and Layland bound for 3 tasks is about 0.779, so 0.50 passes that conservative test.
• I would add interrupt execution, context-switch cost, release jitter, and worst-case mutex blocking before treating the result as final.
• I would confirm every task's calculated response time is below its 2 ms, 5 ms, or 20 ms deadline and validate the assumptions on the target.

I would use a bounded queue with at least 12 entries and choose 16 entries to provide measured margin.

• The ISR would call xQueueSendFromISR with the 16-byte value or, preferably, an index into a preallocated sample pool.
• A 16-entry value queue costs 256 bytes plus queue metadata and absorbs 16 ms of production.
• The consumer would drain all available entries after the 12 ms stall instead of processing only one per wake.
• I would count queue-full events and define whether overflow drops the newest sample, drops the oldest, or raises a data-loss fault.

I would initialize a counting semaphore to 6 so it represents the number of free DMA descriptors.

• A task takes one token before removing a descriptor from the protected free list and starts DMA only after both operations succeed.
• The DMA ISR sends the completed descriptor index with xQueueSendFromISR; a driver task returns it to the free list under the mutex and gives one token.
• A separate short mutex protects free-list metadata because a counting semaphore controls quantity, not mutual exclusion.
• Each requester gets a bounded timeout derived from its deadline, so exhausting all 6 descriptors becomes a visible error rather than an infinite wait.

I would use a binary semaphore because repeated edges may coalesce while one rescan is pending.

• The ISR gives the semaphore with xSemaphoreGiveFromISR and requests a yield if the higher-priority worker becomes ready.
• The worker takes it, reads all GPIO state once, performs debouncing, and blocks again.
• A second give while the semaphore is already available does not count another edge, which matches this rescan requirement.
• If every one of the 200 Hz edges had to be preserved, I would use a counting notification or queue instead.

I would protect the whole I2C transaction with a FreeRTOS mutex owned by task context.

• The mutex covers address, transfer setup, completion, and recovery so bytes from two clients cannot interleave.
• A FreeRTOS mutex provides priority inheritance, while a binary semaphore does not, so the mutex is the correct lock for shared ownership.
• Each caller uses a timeout based on its deadline and releases the mutex on every success and error path.
• I would keep callbacks from taking the same mutex recursively and place long retry delays outside the 2 ms critical section.

I would assign three event bits and wait for all of them without clearing them on a successful wait.

• Link, DHCP, and time-sync owners set bits 0, 1, and 2 when ready and clear their own bit immediately when state is lost.
• The dependent task calls xEventGroupWaitBits with wait-for-all enabled and a finite 1 s recheck timeout.
• Readiness is level state, not an event count, so an event group fits better than three queues.
• After waking, the task rechecks the actual subsystem states because multiple setters and reconnects can race with the wait result.

I would use a direct task notification instead of allocating a queue or semaphore.

• The ISR calls vTaskNotifyGiveFromISR, then portYIELD_FROM_ISR when xHigherPriorityTaskWoken is set.
• The task calls ulTaskNotifyTake with clear-on-exit disabled if every one of the 20,000 completions per second must be counted.
• If only the latest buffer state matters, I would clear on exit and let repeated completions coalesce.
• This design is limited to the single known receiver, which is exactly why it is smaller and faster than a general queue.

I would eliminate unbounded runtime allocation and make the 64 KB budget auditable at build and startup time.

• Task stacks, queues, protocol buffers, and driver requests would come from static storage or fixed-size pools.
• If heap_4 is retained for startup construction, I would freeze allocation after initialization and record the minimum-ever-free heap.
• Fixed pools make exhaustion and maximum latency explicit, while repeated variable-size allocation can fragment the heap over 5 years.
• I would measure task stack high-water marks under stress and reserve at least 20% margin for the worst observed path.

I would supply storage for every kernel object and enable FreeRTOS static allocation support.

• Each task gets a StaticTask_t control block and a fixed StackType_t array passed to xTaskCreateStatic.
• Each queue gets a StaticQueue_t plus a correctly aligned byte buffer, while each mutex is created with xSemaphoreCreateMutexStatic.
• The application provides static idle-task and timer-task memory through the required FreeRTOS callbacks when those tasks are enabled.
• All 8 task stacks and 8 synchronization objects have program-lifetime storage, and a link map verifies the final RAM total.

With an immediate priority-ceiling protocol, H has a one-job blocking bound of 700 us, so the design exceeds its 500 us blocking budget.

• Both resource ceilings equal H's priority because H can lock SPI and calibration, preventing circular lock chains under the chosen protocol.
• The bound is max(700, 300, 200) = 700 us rather than the sum of every lower-priority critical section.
• A ceiling prevents unbounded inversion but does not shorten 700 us, so I would split L's SPI transfer into protocol-safe chunks below 500 us, schedule it outside H's window, or use another controller.
• I would measure actual hold times and rerun response-time analysis for H, M, and L, including ceiling and context-switch overhead.

I would make cancellation cooperative and route every outcome through one structured cleanup path that knows exactly which resources are held.

• A local operation state records SPI ownership, any buffer or descriptor, filesystem ownership, and whether a durable write has begun.
• The filesystem lock uses a bounded wait; on timeout or cancellation, the task stops before starting new work and releases only the resources it actually owns in reverse order.
• The task is never forcibly deleted while holding SPI, and chip select, DMA, descriptors, and the SPI mutex are returned or aborted through the driver owner's documented sequence.
• Persistent changes use staging and a commit marker so cleanup leaves either the old complete record or the new complete record, then fault injection checks every cancellation point.

I would model every descriptor as FREE, DMA_OWNED, or WORKER_OWNED and treat pool exhaustion as an explicit overrun.

• The ISR snapshots the completion status and descriptor ID before any required write-one-to-clear operation, changes DMA_OWNED to WORKER_OWNED, and publishes the ID with xQueueSendFromISR plus a conditional yield.
• The worker validates the ID and generation, processes it, then returns exactly that descriptor to FREE through the driver-owned free list.
• At 10 kHz the pool covers only 800 us of worker lag; if no FREE entry remains, hardware backpressure or DMA stop is used where supported, otherwise the frame is dropped and counted without overwriting owned data.
• Queue-full counts, pool high-water use, maximum worker lag, descriptor-state violations, and sequence gaps are retained and checked under worst-case load.

Only ISRs configured at numeric priority 5 through 15 may call eligible FreeRTOS FromISR APIs.

• On Cortex-M, lower numeric NVIC priority means higher urgency, the opposite direction from FreeRTOS task-priority numbers.
• Priorities 0 through 4 are too urgent to enter the kernel and must communicate through hardware state handled later by an eligible ISR or task.
• CMSIS NVIC_SetPriority normally takes the unshifted value 0 through 15, while configMAX_SYSCALL_INTERRUPT_PRIORITY uses the register-shifted representation on typical ports.
• I would use configASSERT and inspect the port configuration to catch a priority-4 ISR accidentally calling xQueueSendFromISR.

I would keep the 1 kHz tick for active scheduling and enable tickless idle for the 30 s idle intervals.

• A 1 kHz tick gives 1 ms granularity but wakes the CPU 1,000 times per second if ticks are never suppressed.
• Tickless idle programs a low-power timer for the next deadline and advances the kernel tick count after wake.
• I would validate low-power timer drift, maximum suppressible interval, and all wake sources across the full 30 s sleep.
• The 2 ms loop still needs measured latency, and any sub-tick phase requirement should use a hardware timer rather than a faster global tick.

I would program the low-power timer for the earliest kernel or application deadline, so this sleep ends no later than the 5 s deadline.

• The application deadline is registered on the same monotonic time base before the scheduler calculates the suppressible tick interval.
• Sleep entry atomically rechecks pending work and the earliest deadline, then uses the platform's required barriers so an interrupt cannot be lost between the check and WFI.
• On wake, the port converts measured low-power timer ticks into elapsed RTOS ticks and advances kernel time with its documented tickless mechanism before releasing due work.
• If wake is late, the task receives the real elapsed time, records deadline lateness, processes the overdue event once, and enters the defined safe fallback when its tolerance is exceeded.

I would measure worst-case response time on the release build under deliberately hostile concurrent load.

• Hardware timer capture or DWT_CYCCNT records release-to-completion cycles around the function with interrupts and DMA enabled.
• I would run at least 10 million periods while exercising maximum bus traffic, cache states, and all higher-priority ISRs.
• The result includes preemption and mutex blocking, not only the isolated function's average execution time.
• I would report the observed maximum against 500 us with measurement overhead and a justified engineering margin.

I would measure actual update edges with hardware timestamps and separate release jitter from execution jitter.

• Toggle a spare GPIO at task release and at the PWM register write, then capture at least 1 million intervals with a logic analyzer or timer input capture.
• Calculate minimum, maximum, and a histogram, with acceptance based on the worst observed deviation from 1 ms rather than only p99.
• A second trace channel marks long ISRs or scheduler locks so outliers can be correlated with interrupt masking.
• If task wakeup exceeds 20 us, I would move the phase-critical update to a timer compare or DMA trigger and let the task prepare the next value.