ARM Cortex-M Interview (40 Questions)

-

 

Section A – ARM Cortex-M Architecture (1–8)

1.

What is ARM Cortex-M? Where is it typically used?

2.

Differentiate between:

  • Cortex-M0
  • Cortex-M3
  • Cortex-M4
  • Cortex-M7
  • Cortex-M33

3.

Explain the ARM Cortex-M architecture.

Discuss:

  • Harvard Architecture
  • Pipeline
  • Thumb/Thumb-2 instruction set
  • Register organization

4.

What are the advantages of Cortex-M over traditional microcontrollers?

5.

Explain the ARM programmer's model.

Describe the purpose of:

  • R0–R12
  • SP (MSP/PSP)
  • LR
  • PC
  • xPSR

6.

What is the difference between MSP and PSP?

7.

What happens immediately after a hardware reset?

8.

Describe the complete boot sequence of a Cortex-M MCU from reset to main().

Section B – Startup Code & Linker (9–14)

9.

What is the startup file (startup.s or startup.c)? What does it do?

10.

Explain the Vector Table.

Why is it placed at address 0x00000000 (or remapped)?

11.

What is the Reset Handler?

12.

What is a Linker Script? What are its key sections?

13.

Explain the memory layout of an embedded application:

  • .text
  • .rodata
  • .data
  • .bss
  • Heap
  • Stack

14.

What happens before main() is called?

Section C – Interrupts & Exceptions (15–22)

15.

What is the Nested Vectored Interrupt Controller (NVIC)?

16.

How are interrupts prioritized in Cortex-M?

17.

What is interrupt nesting?

18.

Differentiate between:

  • Interrupt
  • Exception
  • Fault

19.

Explain the following exceptions:

  • HardFault
  • MemManage Fault
  • BusFault
  • UsageFault
  • SVCall
  • PendSV
  • SysTick

20.

What is interrupt latency, and what factors affect it?

21.

What is tail chaining? How does it improve interrupt performance?

22.

What is late arrival in the Cortex-M interrupt system?

Section D – Memory System (23–28)

23.

Explain the Cortex-M memory map.

Include:

  • Flash
  • SRAM
  • Peripheral region
  • System control space

24.

What is memory-mapped I/O?

25.

Why are peripheral registers declared as volatile?

26.

What is bit-banding? What are its advantages?

27.

What is the Memory Protection Unit (MPU)? Why is it useful?

28.

How does the Cortex-M architecture support low-power modes?

Section E – Debugging & Performance (29–34)

29.

Explain how JTAG and SWD work. What is the difference?

30.

How would you debug a Cortex-M system that no longer boots after a firmware update?

31.

What is a HardFault? Describe your approach to debugging one.

32.

How would you measure interrupt execution time and CPU utilization on a Cortex-M device?

33.

What debugging tools have you used (e.g., Segger J-Link, Lauterbach, GDB), and how do they help during firmware development?

34.

A firmware image runs correctly in Debug mode but fails in Release mode. What are the possible reasons?

Section F – RTOS & Cortex-M (35–38)

35.

How does an RTOS perform a context switch on ARM Cortex-M?

36.

What roles do SysTick and PendSV play in an RTOS?

37.

Describe the sequence of events during a task switch in FreeRTOS on Cortex-M.

38.

Why is PendSV assigned the lowest interrupt priority in most RTOS implementations?

Section G – Design & Scenario Questions (39–40)

39.

You are designing firmware for an Automotive ECU based on an ARM Cortex-M7 with:

  • CAN FD
  • Ethernet
  • SPI Flash
  • External EEPROM
  • Watchdog
  • RTOS

Explain:

  • Memory layout
  • Interrupt priorities
  • Task organization
  • Boot sequence
  • Fault handling
  • Debug strategy

40.

An Automotive ECU based on Cortex-M occasionally resets while driving. There is no clear error log. Describe your end-to-end debugging methodology, including:

  • Hardware checks
  • Fault status registers
  • Watchdog analysis
  • Stack overflow detection
  • Interrupt analysis
  • Memory corruption detection
  • Use of trace/debug tools

Coding Questions (Frequently Asked)

  1. Write a startup file for a Cortex-M MCU.
  2. Implement a custom interrupt handler.
  3. Configure SysTick to generate a 1 ms interrupt.
  4. Toggle a GPIO using memory-mapped registers.
  5. Relocate the vector table to SRAM.
  6. Implement a simple bootloader jump to an application.
  7. Read and decode HardFault status registers.
  8. Configure the MPU to protect a memory region.
  9. Implement a software delay using SysTick.
  10. Write an ISR-safe circular buffer for UART reception.

Advanced Questions (Very Likely for Your Profile)

Given your background in Bootloaders, Secure Boot, Diagnostics, and FOTA, interviewers may ask:

  • Explain the ARM Cortex-M exception entry and return sequence.
  • How does the hardware automatically save registers on exception entry?
  • What is the EXC_RETURN value, and how is it interpreted?
  • How do MSP and PSP support privilege separation?
  • How would you implement a secure boot chain on Cortex-M?
  • How would you hand over control from a bootloader to an application on Cortex-M?
  • How do TrustZone features in Cortex-M33 improve security?
  • How do you detect and recover from stack overflow in an RTOS?
  • What happens if the vector table is corrupted?
  • How would you debug a bootloader that successfully jumps to the application, but the application immediately enters a HardFault?

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