Debugging Scenarios (60 Questions)

-

 

Section A – Bootloader Debugging (1–10)

1.

The ECU powers ON, but nothing appears on the UART console.

How would you debug it step by step?

2.

The Bootloader starts correctly but never jumps to the application.

Possible reasons?

3.

After the Bootloader jumps, the application immediately enters a HardFault.

Explain your debugging approach.

4.

The Bootloader verifies the image CRC successfully, but signature verification fails.

Possible causes?

5.

Programming completes successfully, but after reset the ECU always enters Bootloader mode.

Why?

6.

The Bootloader hangs during Flash Erase.

Possible causes?

7.

Firmware update works on one hardware revision but fails on another.

How would you isolate the issue?

8.

During OTA, power is lost while programming Flash.

Design the recovery mechanism.

9.

After firmware update, CAN communication no longer works.

Possible reasons?

10.

The Bootloader consumes twice the expected boot time.

How would you optimize it?

Section B – Linux BSP & Device Driver Debugging (11–20)

11.

The Linux kernel boots successfully, but the driver's probe() function is never called.

How do you debug it?

12.

The kernel panics immediately after inserting your driver.

How do you find the root cause?

13.

A character driver loads correctly, but /dev/mydevice is never created.

Possible reasons?

14.

The SPI driver works during boot but fails after several hours.

How would you investigate?

15.

An I²C sensor occasionally returns incorrect values.

How would you debug it?

16.

The Ethernet driver initializes correctly, but packets are never transmitted.

Possible reasons?

17.

DMA transfer occasionally corrupts data.

Possible causes?

18.

USB enumeration succeeds, but data transfer fails.

Debugging steps?

19.

The Device Tree is modified, but the kernel ignores the changes.

Possible reasons?

20.

The board boots only when connected to JTAG.

Why?

Section C – RTOS Debugging (21–30)

21.

The RTOS freezes after running for approximately 48 hours.

How would you debug it?

22.

One task consumes nearly 100% CPU.

How would you identify it?

23.

A high-priority task never executes.

Possible reasons?

24.

The watchdog resets the ECU every few hours.

How would you investigate?

25.

A queue overflows during heavy CAN traffic.

How would you resolve it?

26.

A semaphore is never released.

Possible causes?

27.

Your system occasionally deadlocks.

How would you identify the deadlock?

28.

Stack overflow occurs randomly.

How would you detect it?

29.

An interrupt occasionally executes for more than 500 µs.

How do you optimize it?

30.

An RTOS application works in Debug mode but crashes in Release mode.

Possible reasons?

Section D – ARM Cortex-M Debugging (31–38)

31.

The MCU repeatedly enters HardFault.

Explain your debugging methodology.

32.

The MCU continuously resets.

Possible reasons?

33.

Interrupts stop working after several minutes.

How would you debug it?

34.

SysTick interrupts suddenly stop.

Possible causes?

35.

Memory corruption occurs after several hours.

How would you isolate it?

36.

A peripheral register always reads zero.

Possible reasons?

37.

The MCU enters an unexpected exception.

How do you identify which exception occurred?

38.

Flash programming works only under JTAG debugging.

Possible causes?

Section E – Communication Protocol Debugging (39–46)

39.

CAN node repeatedly enters Bus-Off.

Root cause analysis?

40.

CAN messages are occasionally lost.

Possible reasons?

41.

SPI Flash occasionally returns corrupted data.

How would you debug it?

42.

I²C bus remains permanently busy.

Recovery mechanism?

43.

UART displays random characters.

Possible reasons?

44.

Ethernet link is UP but communication fails.

Possible reasons?

45.

USB device works on Windows but fails on Linux.

How would you debug it?

46.

LIN slave misses responses intermittently.

Possible reasons?

Section F – Secure Boot & FOTA Debugging (47–54)

47.

Signature verification succeeds, but the application crashes immediately after boot.

Possible reasons?

48.

OTA update succeeds, but the Bootloader rejects the new firmware after reset.

Possible causes?

49.

Rollback protection prevents valid firmware installation.

How would you debug it?

50.

HSM verification occasionally fails.

Possible reasons?

51.

A/B update occasionally boots the inactive partition.

Possible causes?

52.

Version compatibility check fails between two logical blocks.

How would you debug it?

53.

CRC passes but SHA-256 verification fails.

Possible reasons?

54.

Firmware update fails only over Ethernet but succeeds over CAN.

Possible reasons?

Section G – System-Level Debugging (55–60)

55.

An Automotive ECU works correctly in the laboratory but fails in the vehicle.

What factors would you investigate?

56.

The ECU resets only when the engine starts.

Possible causes?

57.

The ECU crashes only at high ambient temperatures.

How would you investigate?

58.

Memory usage continuously increases over several days.

How would you identify the source?

59.

A multicore ECU occasionally fails during startup.

How would you debug synchronization issues?

60.

You receive a field-returned ECU with the following symptoms:

  • Random resets
  • OTA failures
  • CAN communication loss
  • Watchdog timeouts
  • HardFaults after firmware updates
  • No clear reproduction steps

Describe your complete debugging strategy, including:

  • Data collection
  • Log analysis
  • Hardware verification
  • Software tracing
  • Reproduction
  • Root cause analysis
  • Corrective action
  • Validation
  • Preventive measures

Live Debugging Questions (Most Frequently Asked)

These are common "whiteboard" or discussion-based questions in senior interviews:

  1. The ECU hangs after 72 hours. What information do you collect first?
  2. How do you distinguish between a hardware issue and a software issue?
  3. How do you debug an intermittent issue that cannot be reproduced?
  4. What tools do you use for low-level debugging?
  5. Explain a challenging bug you solved and your thought process.
  6. How do you perform root cause analysis (RCA)?
  7. What logs do you request from customers for OTA failures?
  8. How do you investigate memory corruption?
  9. How do you identify stack corruption?
  10. How do you debug race conditions in an RTOS?

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