Ola Embedded Software Engineer Interview Questions

The role at Ola demands moving beyond textbook knowledge of C/C++ to a deep, intuitive understanding of how code interacts with physical hardware. Critical concepts include:

• Memory-Mapped I/O and Volatile: You must expertly explain how to read from and write to hardware registers using pointers, and the critical importance of the volatile keyword to prevent compiler optimizations from stripping out essential reads/writes in control loops or ISRs.

• Bitwise Operations and Manipulation: Embedded systems constantly manipulate individual bits within registers to control peripherals (enable/disable interrupts, set GPIO pin states, configure UART baud rates). You should be fluent in setting, clearing, toggling, and testing bits using masks.

• Interrupt Service Routines (ISRs): Understand the entire lifecycle: enabling/disabling interrupts, writing lean and fast ISRs (deferred processing), managing interrupt priorities, and avoiding pitfalls like non-reentrant functions or excessive stack usage.

• Concurrency at the Bare-Metal Level: Even without an RTOS, you deal with concurrency via interrupts. Explain race conditions that can occur between the main loop and an ISR, and the use of critical sections, disable-interrupt guards, and atomic operations.

• Demonstration: In an interview, cite specific examples: *”In my previous project on a motor controller, I used a volatile pointer to access the PWM duty cycle register. The ISR for over-current protection directly modified a bit in the control register using a bit-clear operation (REG &= ~(1 << BIT_POS)) to shut down the FETs within 2 microseconds, while the main loop used a semaphore signaled from the ISR to log the fault.”*

A systematic porting strategy is key. A robust methodology includes:

1. Deep Analysis & Abstraction: First, create a detailed map of the original system: CPU architecture (ARMv7 vs. ARMv8), endianness, memory map, peripheral set (GPIO, ADC, CAN controllers), and the Toolchain. The single most important step is to identify all hardware-dependent code and abstract it into a Hardware Abstraction Layer (HAL) or Platform Abstraction Layer (PAL).

2. Toolchain and Build System Setup: Establish the new cross-compilation toolchain (e.g., arm-none-eabi-gcc). Adapt the build system (Make/CMake) to handle new compiler flags, include paths, and linker scripts. The linker script is crucial as it defines memory layout (Flash, RAM, EEPROM addresses).

3. HAL Implementation and Driver Replacement: Re-implement the HAL modules for the new target. This involves writing or adapting low-level drivers for the new microcontroller’s peripherals. This is where most of the work lies.

4. Incremental Porting and Testing: Don’t move the entire codebase at once. Start by porting the HAL and basic board support package (BSP), then get a simple “blinky LED” test running. Gradually add modules (RTOS, communication stacks, application logic) with unit and integration tests at each stage.

5. Subtle Pitfalls:

   • Alignment and Padding: Different architectures may have strict alignment requirements. Mishandling packed structures can cause hard faults.

   • Interrupt Latency and Priority Levels: The new MCU’s interrupt controller (NVIC) may behave differently. Assumptions about nesting or preemption can break.

   • Timing Delays: Loops based on instruction counts (for(i=0; i<1000; i++)) will behave differently on a 48MHz vs. 200MHz CPU. Replace with hardware timers.

   • Memory Attribute Differences: Cache configurations (on platforms like Qualcomm) versus no-cache on simpler microcontrollers drastically affect performance and require explicit cache maintenance operations in the ported code.

In an EV, an RTOS is the nervous system that ensures deterministic, safe, and efficient operation.

• Determinism and Safety-Critical Control: Functions like Battery Management System (BMS) cell balancing, motor control loops, and regenerative braking have hard real-time deadlines. An RTOS with preemptive, priority-based scheduling and bounded interrupt latency guarantees these tasks execute predictably. You might discuss Rate Monotonic Analysis (RMA) to prove schedulability.

• Reliability through Isolation: An RTOS can facilitate architectural patterns that isolate critical tasks from less critical ones. For example, a fault in the infotainment task (lower priority) should never starve the vehicle control task (higher priority). Memory protection units (MPUs), when used with an RTOS, can prevent errant tasks from corrupting others’ memory spaces.

• Power Management Integration: The RTOS kernel is aware of task states. When the idle task runs (meaning no application task is ready), it can invoke a low-power sleep mode (WFI instruction). More advanced schemes involve the RTOS coordinating with a Power Management IC (PMIC) driver to place different vehicle domains (e.g., telematics, cabin systems) into various sleep states based on vehicle state (parked, charging, driving).

• Example: *”At Ola, using an RTOS like FreeRTOS or SAFERTOS, we would assign the highest priority to the fault-handling task. Medium priority to the real-time control loops for torque vectoring. Lower priorities to data logging and V2X communication. The idle hook would be used to place the core into a wait-for-interrupt state, and a tickless idle mode would be configured to stop the scheduler tick during deep sleep, drastically reducing quiescent current when the scooter is parked.”*

This tests systematic problem-solving under constraints.

1. Layer 1: Post-Mortem Analysis: The first line of defense is leveraging any built-in diagnostics. Did the Watchdog Timer (WDT) reset the system? If so, a task is likely hanging or stuck in an infinite loop. Check the reset status registers on the MCU. If a HardFault or BusFault occurred, the fault status registers (CFSR, HFSR in ARM Cortex-M) and the stacked program counter (PC) and link register (LR) are gold mines. Even without a full debugger, design a mechanism to dump these critical registers to a persistent (EEPROM) or transmitted (CAN) log on a fault before reset.

2. Layer 2: Instrumentation for the Field: Since it’s intermittent, you need more data. Add lightweight, conditional instrumentation. This could be toggling a spare GPIO pin at the entry/exit of critical functions or ISRs. In the field, an engineer can attach a logic probe to capture this timing diagram, revealing unexpected sequences or delays.

3. Layer 3: Forensic Memory Analysis: Implement a “crash dump” module. Upon a fault exception (before reset), the fault handler copies a snapshot of key volatile data—task stack pointers, a ring buffer of recent system events, sensor readings, and the contents of a small, critical memory region—into a reserved section of non-volatile memory (Flash backup sector). On the next boot, this data can be read out and analyzed.

4. Layer 4: Hypothesis and Stress Testing: Based on the clues (e.g., crash seems to happen during rapid acceleration), hypothesize root causes: stack overflow due to a large local array in a newly called function, a race condition between a CAN receive ISR and a control task, or electromagnetic interference (EMI) causing bit flips in memory. In the lab, use tools to inject faults (e.g., heap corruption via malloc poisoning, stack canary checks) and perform extreme environmental stress testing (temperature chambers, voltage margining, RF noise generators) to try to precipitate the failure.

5. Layer 5: Defensive Programming & Monitoring: As a medium-term fix, enhance system robustness. Implement stack canaries, use a Memory Protection Unit (MPU), add redundancy for critical data, and increase the granularity of the watchdog (e.g., use independent task watchdogs in addition to the main system watchdog).

This shift is profound and governs every design decision.

• Requirement Traceability: Every line of code, especially for safety-related functions (ASIL-A to ASIL-D per ISO 26262), must be traced back to a system-level safety requirement. This ensures the software is not just functional but fulfills a specific safety goal (e.g., “Prevent unintended vehicle acceleration”).

• Process Rigor: Adherence to a strict development lifecycle like Automotive SPICE or ISO 26262. This includes mandatory phases (requirements, design, implementation, testing, verification, validation) with defined outputs and reviews. No “quick fixes” bypassing this process.

• Defensive Programming & Fault Tolerance: Assume everything can fail. Sensors can give out-of-range values, communication buses (CAN) can have errors or go silent, and memory can corrupt. Software must implement plausibility checks (e.g., cross-checking wheel speed sensors with motor RPM), sanity limits, and safe states (e.g., “limp-home mode”).

• Robustness in Communication: Use automotive-specific protocols like CAN with robust error detection (CRC, ACK) and higher-layer standards like UDS for diagnostics and AUTOSAR for software architecture. Implement network management for sleep/wake cycles.

• Verification & Validation (V&V): Testing expands dramatically. Beyond unit tests, you need hardware-in-the-loop (HIL) testing with fault injection (simulating sensor shorts, opens), software-in-the-loop (SIL) testing, and extensive real-world durability testing. Code coverage metrics (statement, branch, MC/DC) become pass/fail criteria, not just nice-to-have.

• Tool Qualification: The compilers, debuggers, and static analysis tools used for safety-critical code may need to be “qualified”—proven to behave predictably and without harmful bugs—adding another layer of process overhead and rigor.

This connects low-level coding to high-level vehicle performance metrics.

• CPU Load and Power Draw: The microcontroller’s power consumption scales with clock frequency and active peripheral usage. Aggressive polling loops keep the CPU fully active, wasting power. Optimizing to use interrupts and low-power sleep modes reduces the average CPU load, directly lowering the quiescent current draw from the high-voltage battery pack via the DC-DC converter.

• Algorithmic Efficiency: Compute-intensive tasks like state-of-charge (SOC) estimation for the BMS or motor field-oriented control (FOC) algorithms can be optimized. Using fixed-point arithmetic instead of floating-point on hardware without an FPU saves millions of cycles, reducing CPU time and heat generation. Efficient filtering algorithms (e.g., moving average vs. complex Kalman filters) trade off accuracy for computational savings.

• Thermal Management via Software: Software is responsible for monitoring temperature sensors on the motor controller, battery cells, and power electronics. Based on these readings, it must enact derating strategies. For example, if the motor controller IC temperature rises, the software can gradually reduce the maximum allowable current (torque limit), protecting the hardware. This is a direct software action to manage thermals and prevent permanent damage.

• Communication Scheduling: Blasting high-frequency diagnostic data over CAN or cellular telematics (C-V2X) consumes power. An optimized software strategy might batch and compress logs, or transmit them only when the vehicle is charging (connected to power), thereby preserving battery energy for propulsion.

• Impact: Inefficient software forces the battery to deliver more energy for computation and cooling, reducing the effective range. It can also lead to sustained higher temperatures in electronic control units (ECUs), accelerating electromigration and component aging, potentially shortening the vehicle’s operational lifespan.

Let’s design a Torque Arbitration Manager.

• Requirements: The system shall compute a final torque command for the motor based on inputs from the rider (throttle), traction control system (TCS), regenerative braking system, and fault diagnostics. It shall ensure the command never exceeds safe limits for motor, battery, or vehicle stability. Priority shall be given to fault conditions overriding all others.

• High-Level Design (Patterns): Use a Mediator Pattern. The Torque Manager is the central mediator. It receives requests/commands from various client objects (Throttle Handler, TCS, Regen, Fault Handler). It arbitrates based on predefined priority rules.

• Detailed Design & Safety:

  1. Input Validation: All input signals are validated for range, plausibility, and freshness (timeout checks). A stale throttle signal is ignored, and a default-safe value is used.

  2. Arbitration Logic: Implement a priority hierarchy. For example: Critical Fault (e.g., overcurrent) -> Torque = 0. Stability Control (TCS activating) -> Override rider throttle with calculated stable torque. Rider Throttle -> Normal operation.

  3. Rate Limiting: The final torque command is passed through a software rate limiter (dy/dt limit) to prevent jerks and mechanical stress, even if the rider snaps the throttle.

  4. Output Monitoring: The commanded torque is compared against real-time motor feedback (current, RPM) in an independent “sanity checker” task. A significant mismatch for a sustained period triggers a fault.

  5. Watchdog and Heartbeats: Each client module (TCS, Regen) must provide a heartbeat to the Torque Manager. If any heartbeat is missing, the Torque Manager assumes that module has failed and uses a conservative default for its input.

• Implementation: This would be implemented as a set of tasks/threads in the RTOS. Shared data (torque request queues) would be protected by mutexes or message queues. The mediator’s logic would be simple, deterministic, and heavily unit-tested with scenarios simulating sensor failures and conflicting commands.

OTA is a make-or-break feature for modern EVs.

• Challenge 1: Memory Constraints (Dual Bank Strategy): The microcontroller’s Flash memory is limited. A common strategy is to split Flash into two banks (A and B). The active firmware runs from Bank A. The OTA update package is downloaded and written to Bank B. A bootloader then validates and switches to Bank B on next boot. This requires meticulous linker script configuration and increases Flash size requirements by nearly 100%.

• Challenge 2: Update Integrity and Security: The update process is a major attack vector. It requires:

  • Cryptographic Signature Verification: The downloaded firmware image must be digitally signed by Ola’s private key. The bootloader (a trusted, minimal piece of code) must verify this signature using a public key stored in secure, write-protected memory before allowing a switch.

  • Secure Boot: The chain of trust starts from the immutable boot ROM, to the bootloader, to the main application.

  • Secure Communication: The download channel itself (e.g., 4G/5G module) must use TLS/DTLS.

• Challenge 3: Brick Resistance (Robust Rollback): An update can fail mid-way due to power loss (battery disconnection). The system must be able to recover. This is achieved by:

  • Atomic Switchover: The bootloader only changes the pointer to the active bank after the new image in Bank B is fully written and verified (signature, CRC).

  • Rollback Mechanism: If the new firmware fails a self-test after boot (e.g., cannot communicate with critical ECUs), it must signal the bootloader to revert to the previous known-good version in Bank A. This requires storing metadata (version, status) in a separate persistent sector.

• Challenge 4: Delta Updates and Bandwidth Optimization: Transmitting full binary images is inefficient. Engineers need skills in creating and applying delta updates (binary diffs) to minimize data transfer, which is crucial in areas with poor connectivity and to reduce cellular data costs.

This tests technical diplomacy and root-cause analysis.

• Step 1: Assume Good Faith and Collaborate on Data Gathering: Approach the situation as a joint problem-solving exercise, not a blame game. Propose a collaborative investigation plan.

• Step 2: Review Software Controls for the Failing Component: Together with the hardware engineer, walk through every line of code that controls the suspected hardware. For the MOSFET:

  • Sequencing: Is the enable/disable sequence correct? (e.g., Is the gate driver powered before PWM is applied?).

  • Timing: Could a shoot-through condition occur due to incorrect dead-time insertion in the PWM software? Examine the PWM register settings and the code that modifies them.

  • Fault Reactions: Does the software’s over-current or over-temperature fault ISR disable the outputs fast enough (within the hardware’s specified safe operating area timeline)? Use an oscilloscope to trigger on the fault signal and measure the latency to PWM disable.

• Step 3: Instrument and Reproduce Under Controlled Conditions: Add detailed software logging around the failure event. In the lab, use a test bench to safely stress the system. The hardware engineer might use current probes and thermal cameras, while the software engineer instruments the code to log state variables, ISR entry times, and PWM duty cycles at high frequency leading up to the event.

• Step 4: Analyze the Failure Mode: A blown MOSFET typically indicates over-current (short circuit) or over-temperature. The joint analysis must determine:

  • Was it a single catastrophic event (e.g., a load short caused by hardware, but software didn’t react in time)?

  • Was it a cumulative stress event (e.g., software was operating the MOSFET in its linear region for too long during frequent start/stop cycles due to a bad control algorithm, causing thermal runaway)?

• Step 5: Implement and Verify the Fix: The solution may be a hardware change (e.g., a snubber circuit, a different FET), a software change (e.g., tuning the dead-time, implementing more aggressive temperature derating), or both. The fix must be validated with the same joint instrumentation to prove the issue is resolved.

To future-proof a career at the forefront of EV tech, focus on:

• V2X Communication Protocols: Study the fundamentals of DSRC (IEEE 802.11p) and C-V2X (Cellular V2X, part of 5G). Understand message sets like SAE J2735 (Basic Safety Messages) and their content (position, speed, acceleration, vehicle state). Learn how embedded software would generate, parse, and securely sign/verify these messages with low latency.

• Machine Learning at the Edge (TinyML): ADAS features like obstacle detection or blind-spot monitoring on two-wheelers may require lightweight neural networks running on microcontroller-level hardware (e.g., ARM Cortex-M with CMSIS-NN library) or specialized AI accelerators. Skills in model quantization, pruning, and frameworks like TensorFlow Lite for Microcontrollers will be invaluable.

• Functional Safety (ISO 26262) and SOTIF (ISO 21448): As systems become more automated, formal safety standards become mandatory. Understanding the vocabulary (ASIL, HARA, FMEA, FMEDA) and development processes is crucial. SOTIF (Safety of the Intended Functionality) deals with performance limitations of sensor-based systems, highly relevant for ADAS.

• AUTOSAR Adaptive Platform: While Classic AUTOSAR dominates deeply embedded ECUs, the high-performance compute domains (for infotainment, ADAS) are moving towards Adaptive AUTOSAR, which is POSIX-based (Linux/QNX) and supports dynamic application deployment. Familiarity with its service-oriented architecture (SOARA) and communication frameworks (e.g., SOME/IP) is a forward-looking skill.

• Cybersecurity for Automotive: Beyond OTA, understand intrusion detection systems (IDS) for in-vehicle networks, hardware security modules (HSMs), secure on-board communication (SecOC), and lifecycle management of cryptographic keys throughout the vehicle’s lifespan. Standards like ISO/SAE 21434 guide this domain.