RTOS Interview (40 Questions)

-

 

Section A – RTOS Fundamentals (1–10)

1.

What is an RTOS? How is it different from a General-Purpose Operating System (GPOS)?

2.

What are the key features of an RTOS?

3.

Explain the different types of RTOS:

  • Hard RTOS
  • Firm RTOS
  • Soft RTOS

Provide real-world examples.

4.

What are deterministic systems? Why is determinism important in automotive applications?

5.

What is latency in an RTOS? Explain:

  • Interrupt latency
  • Scheduling latency
  • Context switch latency

6.

What are tasks (threads) in an RTOS? How do they differ from processes?

7.

What states can a task be in?

Explain the complete task state diagram:

  • Running
  • Ready
  • Blocked
  • Suspended
  • Deleted

8.

What is a Task Control Block (TCB)? What information does it typically contain?

9.

What happens internally when a new task is created?

10.

What is an idle task? Why is it required?

Section B – Task Scheduling (11–18)

11.

Explain the different scheduling algorithms:

  • Round Robin
  • Priority-based Preemptive
  • Cooperative
  • EDF (Earliest Deadline First)
  • RMS (Rate Monotonic Scheduling)

12.

What is preemption? How does it work?

13.

Explain context switching. What data is saved and restored?

14.

Why is context switching considered expensive?

15.

How do you calculate CPU utilization in an RTOS?

16.

What is time slicing? When is it useful?

17.

How do RTOSes implement delays such as:

vTaskDelay()

What happens internally?

18.

Can a lower-priority task ever execute while a higher-priority task exists? Explain with examples.

Section C – Synchronization (19–26)

19.

Why do race conditions occur? Give an embedded example.

20.

Explain:

  • Binary Semaphore
  • Counting Semaphore
  • Mutex

When should each be used?

21.

What is the difference between a semaphore and a mutex?

22.

What is a recursive mutex? When is it useful?

23.

Explain priority inversion. Why is it dangerous?

24.

How does priority inheritance solve priority inversion?

25.

What is priority ceiling protocol?

26.

How would you protect shared variables accessed by multiple tasks and ISRs?

Section D – Inter-Task Communication (27–32)

27.

Explain different inter-task communication mechanisms:

  • Queue
  • Message Queue
  • Mailbox
  • Pipe
  • Shared Memory
  • Event Flags

28.

When should queues be preferred over global variables?

29.

How do FreeRTOS queues work internally?

30.

Explain Event Groups. Where are they used?

31.

How can one task notify another without using a queue?

32.

Explain software timers. How are they implemented internally?

Section E – Interrupt Handling (33–36)

33.

How should an ISR communicate with a task?

34.

Why should ISRs be kept as short as possible?

35.

Can you call any RTOS API from an ISR? Why or why not?

36.

What is a deferred interrupt? Why is it useful?

Section F – Advanced RTOS (37–40)

37.

Your RTOS system hangs after running continuously for 72 hours. How would you debug it?

38.

A high-priority task is not executing. What could be the possible reasons?

39.

A watchdog keeps resetting the system every few hours. How would you identify the root cause?

40.

Design an RTOS architecture for an Automotive ECU with the following tasks:

  • CAN Communication
  • Diagnostics (UDS)
  • Sensor Data Acquisition
  • Flash Programming
  • Bootloader Communication
  • Watchdog Service

How would you assign task priorities and justify your choices?

Coding Questions (Very Frequently Asked)

These are often asked during RTOS interviews:

41. (Bonus)

Create two tasks:

  • Producer
  • Consumer

using a queue.

42.

Implement a Binary Semaphore between an ISR and a Task.

43.

Create three tasks with priorities:

  • High
  • Medium
  • Low

Demonstrate priority inversion.

44.

Implement a software timer that toggles an LED every second.

45.

Implement a producer-consumer model using a queue.

Scenario-Based Questions (Most Important)

These are the types of questions that distinguish experienced candidates:

Scenario 1

Your CAN Receive Task is missing messages under heavy bus load.

How would you debug the issue?

Scenario 2

A high-priority Diagnostics Task blocks all other tasks during flash programming.

How would you redesign the scheduling?

Scenario 3

The watchdog expires only during OTA updates.

What are the possible causes?

Scenario 4

An ISR occasionally takes more than 500 µs to execute.

What impact does this have, and how would you optimize it?

Scenario 5

Your system experiences occasional deadlocks.

How would you detect and resolve them?

Advanced Questions for Senior Engineers

Given your background, expect deeper discussions such as:

  • Explain the internals of the RTOS scheduler.
  • How is a context switch triggered by the SysTick timer?
  • How does PendSV facilitate context switching on ARM Cortex-M?
  • Compare FreeRTOS, Zephyr, and VxWorks in terms of architecture and use cases.
  • Explain tickless idle mode and its benefits.
  • How do you profile task execution times and stack usage?
  • How can memory leaks occur in an RTOS, and how do you detect them?
  • Describe strategies to avoid deadlocks and starvation.
  • How would you migrate a bare-metal application to an RTOS?
  • How do AUTOSAR OS concepts differ from general-purpose RTOS implementations?

Comments

Post a Comment

Popular posts from this blog

Fundamental Secure Features in Automotive ECUs

-
Image
 With increasing connectivity and functionality in modern vehicles and IoT devices, security has become a non-negotiable aspect of embedded system design. Automotive ECUs and IoT MCUs are now exposed to threats that can compromise safety, privacy, and system integrity. To mitigate these risks, a suite of fundamental secure features is implemented across the lifecycle of embedded software. This blog outlines six core security pillars that serve as the foundation for robust ECU security: Fundamental Secure Feature I: Secure Boot Fundamental Secure Feature II: Secure Flash Fundamental Secure Feature III: Secure JTAG Fundamental Secure Feature IV: Secure LOG Fundamental Secure Feature V: Secure UDS Fundamental Secure Feature VI: Secure On-Board Communication (SecOC) These six foundational security features—Secure Boot, Secure Flash, Secure JTAG, Secure Log, Secure UDS, and Secure On-Board Communication (SecOC)—are critical for building a trustworthy embedded system. Whether in automoti...
Read more

Overview of ISO/SAE 21434 Standard

-
Image
ISO/SAE 21434, jointly published by the International Standardization Organization (ISO) and the Society of Automotive Engineers (SAE), serves as a comprehensive cybersecurity framework for electronic systems within road vehicles. Developed to bolster cybersecurity across the entire lifecycle of automotive products, this standard outlines essential vocabulary, objectives, requirements, and guidelines. Purpose and Scope: The primary objective of ISO/SAE 21434 is to enhance cybersecurity measures for vehicles throughout their lifecycle. By providing a standardized framework, this standard facilitates the establishment of cybersecurity policies, risk management practices, and a cybersecurity-oriented culture within organizations operating in the automotive industry. Three Pillars: ISO/SAE 21434 is structured around three main pillars: Cyber Security Governance:   Establishing policies, processes, and cultural norms to govern cybersecurity activities within organizations. Risk Man...
Read more

Fundamental Secure Feature I: Secure Boot

-
Image
What is it? Secure Boot is a mechanism that verifies the authenticity and integrity of software code stored in flash memory before allowing the system to execute it. The MCU will only boot the application if the code has not been tampered with. Why is it needed? Prevents unauthorized firmware execution. Protects against malicious code injection during the boot process. Blocks attempts to bypass security checks by tampering with the bootloader. Ensures the ECU does not boot into a compromised or corrupted state. 🔍 For example, an attacker might modify the bootloader to disable security features after boot. Secure Boot prevents this by enforcing integrity checks from the very first instruction. Types of Secure Boot: Symmetric-Based Secure Boot Uses shared keys for both signing and verification. Easier to implement, but key management is critical. Asymmetric-Based Secure Boot Uses a private-public key pair. The bootloader verifies the signature of the firmware using a public key, while t...
Read more