Embedded Systems Interview Questions

"A microcontroller is a whole small computer on one chip. It has the CPU, flash for the program, some RAM, and peripherals like timers, UART, SPI and an ADC built in, so I can power it up and run my code straight from flash. It's cheap, boots in milliseconds and can sleep at microamps. A microprocessor is mostly just the CPU. It needs external DRAM and storage, it usually has a memory management unit, and it typically runs Linux or another full operating system. So for a thermostat, a motor controller or a sensor node, I'd pick a microcontroller because I need tight timing, long battery life and a low bill of materials. If the product needs a rich touchscreen, a full networking stack or lots of software, I'd go for an application processor and accept the extra power, cost and boot time."

"Flash is non-volatile, so it holds the program code and anything marked const, like a lookup table. It's also where the starting values of initialised globals are stored. SRAM is fast but loses everything at power-off, so at run time it holds the globals, the stack and the heap if there is one. EEPROM, when the chip has it, is small non-volatile memory I can write a byte at a time, which suits settings and calibration values. A lot of newer parts don't have real EEPROM and emulate it in a flash page instead, which means wear levelling and erasing whole pages. So in practice a global like int count = 5 lives in RAM, but its 5 is copied from flash at startup. A const table stays in flash and costs no RAM, at least on a Cortex-M; some 8-bit parts need a special keyword for that. And a local variable sits on the stack, or just in a register if the compiler can keep it there."

"In my final-year project, and later at work, I've followed the same order. Before firmware, I power the board from a bench supply with a current limit and check each rail and the idle current. Then I check the debug probe connects over SWD, then I blink an LED and get a UART printing, running on the internal oscillator first. On one board at my last job everything worked on the internal clock but the chip hung when switching to the external crystal. I scoped the crystal and it wasn't oscillating reliably. The load capacitors on the schematic didn't match the crystal's datasheet. We fixed the values by hand on the prototypes, and I added a timeout in the clock setup so a dead crystal would fall back and report an error instead of hanging. That check is now in my bring-up list for every new board."

"On a Cortex-M, which is what I've used most, the core comes out of reset and reads the first two words of the vector table. The first is the initial stack pointer, the second is the address of the reset handler, and it jumps there. The reset handler is the startup code, often assembly or a small C file from the vendor. It copies the initial values of the .data section from flash into RAM, fills .bss with zeros so uninitialised globals really start at zero, and usually calls a system init function to set up clocks and sometimes the FPU. If it's C++, it also runs the global constructors. Only then does it call main. This matters when debugging: if a global has a garbage value at startup, or the board hangs before main, the problem is usually in the linker script or startup code, not in my application."

"A watchdog is a counter, usually clocked from its own oscillator, that counts down and resets the microcontroller if the software doesn't refresh it in time. The whole point is recovery when the code hangs. The classic mistake is refreshing it in a periodic timer interrupt. The interrupt keeps firing even if every task is stuck, so the watchdog never bites. In a multitasking system I have each critical task set its own check-in bit each time round its loop. A single supervisor, often a low priority task, refreshes the watchdog only if all the bits are set, then clears them. If any task stops, no refresh happens and the chip resets. On boot I read the reset-cause register, and if it was the watchdog I log which task failed to check in, so the reset becomes evidence, not just a silent reboot."

"I'd split flash into a small bootloader at the reset address and two application slots. The bootloader is kept tiny and ideally never updated, because it's the one thing that can't be recovered in the field. The running app downloads the new image into the inactive slot, so the working image is never touched. When the download finishes, the bootloader or the app checks a hash of the whole image and verifies a signature, so a corrupted or unofficial image is refused. Then it marks the new slot as pending and reboots. The bootloader boots it on trial. The new firmware has to confirm itself, say after it has connected to the server and passed self-tests. If it crashes or resets before confirming, the bootloader falls back to the old slot. Because state is only changed after writes are verified, a power cut at any point still leaves one bootable image."

"I'd first explain that the watchdog is doing its job. Something is hanging, and without the watchdog the unit would just freeze in front of the customer instead of recovering in a second or two. So disabling it might make the demo worse, not better. Then I'd spend the next hour finding out what's actually stuck. If we log the reset cause and which task missed its check-in, that often points straight at the bug, and it might be a quick fix. If we can't fix it by tomorrow, I'd offer options: a demo build with a longer timeout, or a script that avoids the feature that triggers it. If the manager still wants it off for the demo, I'd make a separate build that's clearly labelled, make sure it can never go to production, and put the real fix at the top of the list after the demo."

"First the peripheral, say a UART that just received a byte, sets its interrupt flag. The interrupt controller checks that this interrupt is enabled and that its priority is higher than whatever is running now. If so, the CPU finishes or abandons the current instruction and saves the context. On a Cortex-M the hardware pushes eight registers onto the stack automatically: R0 to R3, R12, the link register, the program counter and the status register, plus the floating point registers if the FPU is in use. Then it fetches the handler address from the vector table and jumps to my ISR. Inside, I read the data and make sure the flag gets cleared, otherwise the interrupt fires again the moment I return. On return, the saved registers are popped and main carries on as if nothing happened. If another interrupt is pending at that point, the core can go straight into it without fully unstacking, which saves time."

"My main rule is get in and get out. An ISR should read what the hardware has for it, clear the interrupt flag, maybe push a byte into a buffer or set a flag, and return. The real processing happens in the main loop or in a task that the ISR wakes up. Things I never put in an ISR are delay loops, waiting on a peripheral, printf, malloc, or anything that might block, because every microsecond I spend there delays other interrupts and can make the system miss events. printf is especially bad because it's slow and often not reentrant. Any variable shared with the main code is declared volatile and read in a way that can't be torn. And with an RTOS I only call the functions marked as safe from interrupts, never a normal blocking one."

"Polling means my code keeps checking a status flag. It's the simplest and it's fine for something like waiting a few microseconds for an SPI transfer to finish, or reading a slow sensor once a second in a simple loop. The cost is wasted CPU and power, and I can miss events if the loop gets busy. Interrupts suit events that are rare or unpredictable but need a quick reaction, like a button press or a received packet, and they let the CPU sleep in between, which is huge for battery life. But at very high rates the overhead of entering and leaving an ISR for every byte adds up. That's where DMA comes in. For a continuous ADC stream or a large UART or SPI transfer, I let DMA move the data into a buffer and only take an interrupt when half or all of the buffer is full."

"On a 32-bit core, reading a 64-bit value takes two separate loads. If the interrupt fires between them and the ISR updates the timestamp, I end up with the low half from one value and the high half from another, which is a torn read. volatile doesn't help here. It only makes the compiler actually read memory every time, it says nothing about atomicity. The simplest fix is a tiny critical section: save the interrupt mask state, disable interrupts, copy the value into a local, then restore the previous state rather than blindly enabling, so it's safe if interrupts were already off. It's only a few instructions, so latency barely changes. Another option is reading the high word, the low word, then the high word again and retrying if it changed. The same issue hits read-modify-write, like count++ in main while the ISR also changes count."

"volatile tells the compiler that a variable can change, or that a write to it matters, in ways it can't see from the code. So it must not keep the value in a register, merge reads, or remove writes that look pointless. Without it, the optimiser can turn while (!ready) into an endless loop, because from its point of view nothing inside the loop changes ready. In firmware I need it in three main places. Hardware registers, because a status register changes on its own and a write to a data register has a side effect. Variables shared between an ISR and the main code. And buffers that DMA writes into. What volatile doesn't do is make access atomic or protect a read-modify-write. So for shared data I still need a critical section or atomic operations on top of it."

"I define the field's position and a mask of four ones shifted up by four. Then I read the register once into a local variable, clear the field with AND NOT mask, OR in the new value shifted into place and masked so a too-big value can't spill into other bits, and write the result back once. The things that bite you are around read-modify-write. If an ISR changes another bit in the same register between my read and my write, my write puts back the old value and its change is lost, so either both sides use a critical section or I use the chip's separate set and clear registers if it has them. Also, some status registers are write-one-to-clear, so reading and writing back the whole register can clear flags I never meant to touch. For those I write only the bits I mean to clear."

"I use a single-producer, single-consumer ring buffer. The ISR is the only code that writes head, and the main loop is the only code that writes tail. When a byte arrives, the ISR works out the next head, and if that would equal tail the buffer is full, so it drops the byte and I count that as an overrun. Otherwise it stores the byte and only then moves head. The main loop checks if tail equals head, which means empty, and if not it reads a byte and moves tail. I keep one slot empty so full and empty look different, and I make the size a power of two so wrapping is a cheap mask. Because each index has one writer and each update is a single aligned word store on a single-core chip, I don't need to disable interrupts. On a multi-core chip I'd add memory barriers."

"The rate I get is the timer's input clock divided by the prescaler and then by the reload count. On a lot of parts, including the STM32 style timers I've used, both registers hold the value minus one. So with 48 MHz feeding the timer, I set the prescaler to 47, which gives a 1 MHz count, one tick per microsecond. Then I set the auto-reload to 999, so the counter overflows after 1000 ticks, once every millisecond. I enable the update interrupt and clear its flag in the handler. Two things I always check. First, the clock actually feeding the timer, because it often comes through a bus prescaler and isn't the core clock. Second, whether I even need a hardware timer, because on a Cortex-M the SysTick timer is made for exactly this: load it with the core clock divided by 1000, minus one."

"A timer counts up from zero to a period value and then starts again. In PWM mode it also has a compare register. In the usual edge-aligned mode, at the start of each period the output pin goes high, and when the counter reaches the compare value it goes low. So the period value, together with the timer clock and prescaler, sets the PWM frequency, and the compare value sets the duty cycle, which is how much of each period the pin is high. If the period is 1000 counts and the compare is 250, the pin is high a quarter of the time. I use it for LED dimming, motor speed and servo control. The trade-off is resolution: if I push the frequency up, there are fewer counts per period, so I get fewer duty-cycle steps. For motors I'd also keep the frequency above the audible range so it doesn't whine."

"The tempting version is to compute a deadline as start plus timeout and check if now is past it. That breaks near the wrap. If start is just below the maximum, the deadline wraps to a small number and the check passes instantly. With a 32-bit millisecond counter that happens after about 49.7 days, which is exactly the kind of bug that shows up only in the field. The fix is to always subtract: now minus start, both unsigned. Unsigned arithmetic in C is defined to wrap, so even when now has rolled over to a small value, the subtraction gives the correct elapsed time. Then I compare elapsed against the timeout. That's correct as long as the timeout is less than the counter's full range. With a 16-bit counter on a 32-bit core I'd cast the result back to 16 bits, because C promotes both to int before subtracting."

"UART has no clock line. Each side just agrees on a baud rate, and each byte is framed with a start bit and a stop bit. It's point-to-point, so I use it for debug consoles, GPS modules or talking to another processor. SPI has a clock driven by the master, data lines in both directions and a chip select per device. It's full duplex and can run at many megahertz, so it suits displays, flash chips and fast ADCs, but each extra device costs a pin and there's no built-in acknowledge. I2C uses just two wires, SDA and SCL, shared by many devices, each with its own address, and every byte is acknowledged. It's slower, usually 100 or 400 kHz, but great for lots of slow sensors. So for a temperature sensor I'd happily share an I2C bus. For a high-rate IMU or flash I'd pick SPI."

"I2C lines are open drain. Every device can pull SDA or SCL low, but nobody drives them high. The pull-up resistors do that. It means two devices can never short against each other, and it's what makes clock stretching and multi-master arbitration possible. The resistor value is a trade-off: too big and the edges are slow because of bus capacitance, too small and you burn current and devices struggle to pull low. For a register read, the master sends a START, which is SDA falling while SCL is high. Then the 7-bit address with the write bit, and the sensor pulls SDA low on the ninth clock to acknowledge. Then the register number, acknowledged again. Then a repeated START, the address with the read bit, and the sensor sends data bytes. The master acknowledges each except the last, which it NACKs, and ends with a STOP."

"Bytes that look shifted by one bit usually mean an SPI mode mismatch. SPI has four modes, set by two bits. CPOL is whether the clock idles low or high. CPHA is whether data is sampled on the leading edge of each clock pulse or on the trailing edge. Mode 0 idles low and samples on the rising edge. Mode 3 idles high and also samples on the rising edge, which is why many chips accept either. If my master samples on the other edge, it catches every bit just as it's changing, and I get data that's off by a bit or just noisy. So I'd check the device's datasheet timing diagram and set the matching mode. I'd also confirm the bit order, since most devices are MSB first, and that chip select stays low for the whole command. Then I'd put a logic analyzer on the four lines to prove it."

"CAN is a two-wire differential bus, which makes it resistant to the electrical noise you get from motors and ignition. There's a 120 ohm terminator at each end. Messages carry an identifier rather than a destination address, and any node can start sending when the bus is idle. If two start together, arbitration happens bit by bit on the identifier. A 0 is dominant and a 1 is recessive, so if one node sends a 1 but reads back a 0, it knows someone else has priority and stops sending. The node with the lowest ID wins and its frame goes through untouched, so no bandwidth is lost, and the loser retries later. On top of that, frames have a CRC, receivers acknowledge in a dedicated slot, and each node keeps error counters. A faulty node goes error passive and eventually bus-off, so it can't take the whole network down."

"For a small device, like a sensor that wakes up, reads a value, sends it and sleeps, a super loop with interrupts is my first choice. It's small, there's no scheduler to reason about, and timing is easy to check. The trouble starts when the jobs multiply and have different deadlines. If one part of the loop occasionally takes 50 milliseconds, say writing to flash or handling a network stack, everything else waits, and I end up writing state machines everywhere to break work into pieces. That's when an RTOS pays off. I can give the motor control loop a high priority task, put communication in a lower one, and the scheduler makes sure the urgent work runs on time. But it isn't free. Each task needs its own stack, so RAM goes up, and I have to deal with shared resources, deadlocks and priority inversion."

"The rule is simple: the highest priority task that's ready is the one running. Every task is in one of a few states. Running is the one on the CPU. Ready means it could run, but something higher is running. Blocked means it's waiting for something, like a delay, a semaphore or data in a queue, and it uses no CPU while it waits. Suspended means it's been taken out of scheduling until something resumes it. When an interrupt gives a semaphore that a higher task is blocked on, that task becomes ready, and if the ISR asks for a switch on exit, it runs as soon as the interrupt returns rather than at the next tick. Tasks at the same priority take turns on each tick if time slicing is on. The practical lesson is that a high priority task must block regularly. If it spins in a busy loop, everything below it starves, including the idle task."

"I pick by what I need it to do. If I only need to signal, say an ISR telling a task that a DMA transfer finished, a binary semaphore does it, or a task notification, which is lighter. Nobody owns it, and the ISR gives it with the from-ISR call. If events can pile up before the task runs, or I'm handing out a pool of buffers, a counting semaphore keeps the count so nothing is lost. If two tasks share the SPI bus or a UART, I use a mutex. It has an owner, only the task that took it can give it back, and in most RTOSes it comes with priority inheritance, which a semaphore doesn't. And if I need to pass the data itself, like readings from a sensor task to a logging task, I use a queue. It copies each item in and blocks the reader until something arrives, which often removes the shared variable altogether."

"Say I have three tasks. The low priority one takes a mutex to use the SPI bus. Then the high priority task wakes up and wants the same bus, so it blocks on the mutex, which is expected and should be short. But now a medium priority task that doesn't need the bus becomes ready. It preempts the low task, because it's higher, and runs for as long as it likes. The low task can't finish and release the mutex, so the high task is effectively waiting on the medium one. That's priority inversion, and it can blow a deadline or trigger a watchdog reset. Priority inheritance fixes it by temporarily raising the mutex holder to the priority of the highest task waiting, so medium can't preempt it. Priority ceiling raises the holder, the moment it takes the lock, to the highest priority of any task that uses that lock. In FreeRTOS, mutexes have inheritance but plain binary semaphores don't."

"The pattern is deferred interrupt processing. The ISR does the bare minimum with the hardware, then signals a task that does the real work. In FreeRTOS I'd use a task notification or a semaphore give, and inside an ISR I must use the FromISR version. Those functions take a flag that gets set if the call woke a task with a higher priority than the one that was interrupted. At the end of the ISR I pass that flag to portYIELD_FROM_ISR, so the scheduler switches straight to that task when the interrupt returns instead of waiting for the next tick. A mutex is off limits because taking it may have to block, and an ISR can never block. A mutex also has an owner and priority inheritance, which only mean something for tasks. So if an ISR and a task share data, I use a short critical section or a queue instead."

"For a years-long battery life, the device has to be asleep almost all the time, so the average current is dominated by the sleep current and by how long and how often it wakes. I'd start by measuring a full cycle with a current profiler, because the surprise is usually somewhere unexpected, like a sensor left powered or a pull-up leaking. Then I'd make sure the chip uses the deepest sleep mode that can still wake on the RTC or the pin I need, with everything event-driven so nothing polls. When awake, I turn on only the peripherals I need, run fast, and go back to sleep, which usually beats running slowly. I'd power sensors through a load switch, batch radio transmissions since the radio is often the biggest cost, and set unused pins so they don't float, because floating inputs can draw current."

"At my last company a wireless sensor was meant to last two years but our bench measurements pointed to well under one. I set up a current profiler across a full cycle and saw two things. The sleep current was higher than the datasheet promised, and the radio was waking far more often than we thought. The sleep current turned out to be two unused pins left as floating inputs and a sensor we never powered down. Configuring the pins and switching the sensor through a load switch fixed most of it. The radio was sending every reading straight away. I proposed batching readings and sending them every few minutes, which meant the dashboard would show data a little later. I took that to the product owner, since it was a user-facing change. They agreed, and with both fixes the projection came back comfortably above target."

"First, I don't just set a breakpoint in the HardFault handler and stare at it. The hardware has already stacked eight registers, so I check bit 2 of the EXC_RETURN value in LR to see whether the main or process stack was in use, then read the stacked program counter and link register from that frame. The stacked PC points at, or very near, the faulting instruction, and LR usually shows who called that function. On an M3 or above I read the fault status registers next. The HardFault status register says if another fault escalated, and the configurable one says whether it was a bus fault, a memory management fault or a usage fault, like an undefined instruction or, if that trap is on, a divide by zero. The fault address registers help when they're marked valid. Then I look the PC up in the disassembly. One catch is an imprecise bus fault, where the PC is past the real culprit because the write was buffered."

"At my last company we had an I2C temperature sensor that returned garbage maybe once in a few hundred reads. The software team assumed a noisy board and the hardware team assumed a driver bug. I put a logic analyzer on SDA and SCL and triggered on a NACK. The captures showed that the bad reads always came right after a long flash erase, and the scope showed the rising edges were clean, which ruled out weak pull-ups. Looking closer, our driver had a timeout that assumed the sensor never stretched the clock, but the sensor did stretch it during its conversion, and when the flash erase delayed our ISR, the timeout fired mid-byte. We fixed the driver to honour clock stretching and moved the erase into smaller chunks. Since then I start with a capture of the bus before arguing about whose fault it is."

"I'd be kind about it, because it's a very natural thing to try, but I wouldn't let it ship. A printf in an ISR is slow and changes the timing of everything around it, so the bug disappearing tells us it's timing-related, which is useful, but not that it's fixed. It'll come back with a different compiler setting or a faster clock, probably in the field. It can also cause its own problems, since printf may not be reentrant and blocks other interrupts while it runs. I'd suggest we pull it out and observe without disturbing much: toggle a spare GPIO at the start and end of the ISR and at the main loop's critical points, and watch them together on a logic analyzer. Or write timestamps into a RAM buffer and dump it later. Once we can see the overlap, we fix the real race."

"First I'd stop guessing and get data from the devices. I'd make sure every unit records its reset cause from the reset-cause register, its uptime before the reset, and on a fault, the stacked PC and fault registers saved in a RAM area that isn't cleared at startup or in flash. That gets reported on the next boot. Then I'd look for patterns. If the uptime is always roughly the same, I think of a counter overflowing, a slow memory leak or heap fragmentation, or a stack creeping up. If it's brown-out resets clustered at certain sites, it's more likely power quality or a battery sagging in the cold. Once I have a theory, I try to reproduce it faster, for example by starting timers near their wrap value, or running a stress test with supply dips. And I'd ship the fix with the same logging, so the field data proves it worked."