Common embedded firmware interview questions

This article tries to list the commonly used embedded software interview questions asked to entry level and middle level job openings. This article will be updated with new questions as and when available.

• How an ISR is getting invoked during an interrupt trigger?

  An ISR is invoked when a peripheral event (like a timer overflow, GPIO edge, or UART receive) sets an interrupt flag, which the interrupt controller checks and signals to the CPU if enabled. The CPU then finishes its current instruction, saves the execution context (PC, status registers, etc.) onto the stack and fetches the ISR address from the interrupt vector table. The control then jumps to the ISR where the service code runs (typically clearing the interrupt flag and handling the event). On completion of the ISR, a special return from interrupt instruction restores the saved context so that the normal program execution resumes. Higher priority ISRs can preempt lower ones (nested interrupts). ISR latency depends on stacking and vector fetch. The best practice is to keep ISRs short and defer heavy work to tasks.

• How does mutex works in RTOS?

  A mutex (mutual exclusion) in an RTOS is a synchronization primitive used to protect shared resources by allowing only one task at a time to access them. When a task requests a mutex, if it’s free, the RTOS grants it and marks the mutex as “owned,” but if it’s already taken, the requesting task is put into a blocked state until the mutex becomes available. Once the owning task finishes and releases the mutex, the RTOS wakes up one of the waiting tasks (usually based on priority) and hands it the ownership. Unlike binary semaphores, mutexes are “owned,” meaning only the task that locked it can unlock it. Mutex mechanisms often implement priority inheritance (or priority ceiling) to temporarily boost the priority of the mutex holder if a higher priority task is waiting, preventing priority inversion problems. In short, mutexes ensure safe access to critical resources with fairness and deterministic scheduling.

• Explain CAN protocol from a software implementation perspective?

  The CAN (Controller Area Network) protocol is handled using a layered approach where the application interacts with a CAN driver or middleware rather than directly dealing with the physical bus. The software configures the CAN controller with bit timing parameters, baud rate, filters, and acceptance masks, then transmits data by writing message frames (ID, control bits, and data payload up to 8 bytes in classic CAN or 64 in CAN FD) into the controller’s transmit buffer. The CAN controller handles arbitration (based on message ID priority) and sends the frame onto the bus, while received frames trigger interrupts where the ISR reads from the receive buffer and passes the data up to higher layers. Error handling is mostly automated by the CAN controller, but software monitors error counters and bus off conditions to recover communication. Typically, middleware or RTOS tasks implement message queues, filtering, and callback mechanisms to decouple ISRs from application logic, ensuring deterministic and non blocking communication.

• Why is structure padding used in C. What would happen if there is no structure padding on a 32-bit machine?

  Structure padding in C is used so that data members are aligned to the natural word boundaries of the processor (e.g., 4 bytes on a 32-bit machine), which allows the CPU to fetch and store data efficiently. Without padding, the compiler would pack members back to back, leading to misaligned accesses where, for example, a 4 byte int might start at a non 4 byte address, forcing the CPU to perform multiple memory cycles or even raising an alignment fault on some architectures. This in turn would significantly degrade performance or cause runtime exceptions on strict alignment processors, whereas with padding, the compiler inserts unused bytes between members so that each is properly aligned, trading off some memory overhead for faster and safer memory access.

• What are the operating modes in ARM Cortex M processors?

  ARM Cortex-M processors mainly operate in two modes: Thread mode and Handler mode. Thread mode is where normal application code runs, and it can be entered either after reset or when returning from an exception, while Handler mode is entered whenever an exception or interrupt is serviced (e.g., SysTick, IRQ, or fault handlers). In addition, execution privilege levels also exist in ARM Cortex which are privileged (full access to system resources) and unprivileged (restricted access, often used with an RTOS for task isolation). User tasks typically run in Thread mode (privileged or unprivileged), while all interrupts and exceptions execute in Handler mode at privileged level, ensuring secure and predictable exception handling.

• Which is a lightweight interface; Mutex or binary semaphore?

  A binary semaphore is considered a light weight interface than a mutex because it is essentially a simple signaling mechanism without ownership semantics. The binary semaphore just indicates availability of a resource or event, and any task can give or take it. A mutex, on the other hand, carries additional logic such as ownership tracking (only the task that locked it can unlock it) and often implements priority inheritance to avoid priority inversion, which adds overhead. Mutexes are better suited for protecting shared resources safely, binary semaphores are more lightweight and efficient when only synchronization or signaling between tasks/ISRs is required.

• Why we use volatile keyword in embedded firmware. Explain the program execution behavior with respect to memory access with the volatile variable?

  In embedded firmware, the volatile keyword is used to tell the compiler that a variable’s value can change at any time outside the normal program flow (e.g., updated by hardware registers, ISRs, or other threads), so it must always fetch the value directly from memory rather than using cached values in CPU registers. Without volatile keyword, the compiler might optimize reads/writes by keeping the variable in a register, leading to incorrect behavior such as missing a hardware status flag change or looping infinitely because the updated value in memory was never re read. The type qualifier volatile forces every access to go to memory, preventing the compiler from relying on a cached CPU register value.

• How do you write a read-only register access variable in C given a hex number as the register address. Also, explain how can we access individual bytes as well as the entire 32-bit register in C efficiently?

  In embedded C, a read only hardware register is typically declared as a pointer to a volatile const type at the given hex address, ensuring the compiler always reads from memory and never allows modification. For example, a 32-bit read-only register at address 0x40021000 can be written as:

  #define REG32 (*(volatile const uint32_t*)0x40021000)

  This allows direct access to the entire 32-bit register as REG32. To efficiently access individual bytes, the same address can be casted to an 8-bit pointer and index it,

  #define REG8 ((volatile const uint8_t*)0x40021000)
  uint8_t byte0 = REG8[0];  // lowest byte
  uint8_t byte1 = REG8[1];  // next byte

  This is to get fine-grained byte access while still being able to read the full 32-bit register in one instruction. The key is using volatile (to ensure real hardware reads) and const (to enforce read-only), with appropriate type casting for 8-bit vs. 32-bit views of the same memory-mapped register.

• What would happen if one member of a structure is made static?

  In C, it is not allowed to have static struct members; the compiler will throw an error if a static member is declared inside a struct. In C++, static struct/class members are allowed and exist as a single shared variable across all instances, with no impact on the object’s size.