Embedded-C Firmware and Development Tools

Introduction

Embedded firmware connects software abstractions to physical hardware. Unlike general-purpose application software, it executes under strict constraints: limited memory, real-time deadlines, direct peripheral access, power budgets, asynchronous interrupts, and potentially hazardous outputs. A seemingly harmless C expression can alter an entire hardware register, while an omitted volatile qualifier can cause a polling loop to fail after optimization.

Professional firmware development therefore requires more than knowledge of C syntax. Engineers must understand the compiler, startup sequence, linker, memory map, hardware abstraction, debugging interfaces, and measurement equipment as one integrated system. This chapter develops that understanding using portable C practices and GNU-style examples. Device-specific details must always be verified against the processor architecture, microcontroller reference manual, compiler documentation, and application binary interface (ABI).

Learning Objectives

After studying this chapter, students should be able to:

• write predictable embedded C using fixed-width types, masks, pointers, structures, volatile, and const;
• distinguish language-level operations from hardware effects such as read-to-clear and write-one-to-clear behavior;
• explain reset, vector-table, data initialization, and C runtime startup;
• place code and data using a valid linker script and interpret ELF and map files;
• design maintainable register access and hardware-abstraction layers;
• use cross-compilers, IDEs, simulators, debuggers, JTAG/SWD probes, and logic analyzers appropriately;
• diagnose firmware by correlating source code, machine state, memory placement, and observed signals; and
• apply reliability, security, and reproducibility practices throughout the firmware life cycle.

1. The Embedded-C Execution Model

Embedded C is usually compiled on a host computer for a different target processor. A cross-compiler translates source files into target object files. The linker resolves symbols, places sections at target addresses, and produces an executable and linkable format (ELF) file. Post-processing tools may derive Intel HEX or raw binary images.

C does not define peripheral registers, interrupt behavior, memory buses, or startup after reset. These are supplied by the target architecture, device documentation, ABI, compiler extensions, startup code, and linker configuration. Consequently, code can be valid C yet still be invalid for a particular device.

1.1 Data types and integer behavior

Use <stdint.h> types when width is important:

Exact-width types are optional in the C standard if a platform cannot represent them without padding, although they are available on most microcontrollers. unsigned int is not guaranteed to be 32 bits. char signedness is implementation-defined.

Unsigned arithmetic is defined modulo 2^N, where N is the width in bits. Signed overflow, by contrast, is undefined behavior. Shifting by a negative count or by a count greater than or equal to the promoted left operand’s width is also undefined. A left shift of a signed value can introduce additional undefined behavior, so unsigned operands are preferred for masks.

2. Bitwise Register Operations

Peripheral configuration is commonly encoded as individual bits or multi-bit fields. If bit positions are numbered from zero, a single-bit mask is

where M_n is the mask and n is a valid position smaller than the width of the unsigned operand. In C, a width-matched expression such as UINT32_C(1) << n is preferable for a 32-bit register.

For a value r and mask m:

For a field of width w beginning at position p, its unshifted mask is

and its positioned mask is F_p = F \ll p. These formulas require 1 \le w and a field that fits the register. In C, avoid evaluating 1u << w when w equals the operand width. A field value x can be inserted by

reg = (reg & ~FIELD_MASK) |
      ((x << FIELD_POS) & FIELD_MASK);

Worked Example 1: Configuring a control register

Suppose a 32-bit control register contains an enable bit at position 0 and a three-bit mode field at positions 6–4. The required mode is binary 101, and unrelated bits must be preserved.

#define CTRL_ENABLE       (UINT32_C(1) << 0)
#define CTRL_MODE_POS     4u
#define CTRL_MODE_MASK    (UINT32_C(7) << CTRL_MODE_POS)

uint32_t value = CTRL_REG;
value = (value & ~CTRL_MODE_MASK) |
        ((UINT32_C(5) << CTRL_MODE_POS) & CTRL_MODE_MASK);
value |= CTRL_ENABLE;
CTRL_REG = value;

The mode contribution is 5 << 4 = 0x50; the enable contribution is 0x01. Only those fields are changed.

This read-modify-write sequence is not universally safe. It can lose an interrupt-time update, and it is unsuitable if a register contains read-to-clear, write-one-to-clear, or reserved bits with special requirements. Prefer dedicated SET, CLEAR, and TOGGLE registers when provided. Otherwise, use the access sequence specified by the manufacturer and protect shared state where necessary.

3. Pointers and Memory-Mapped Input/Output

In memory-mapped I/O, peripheral registers occupy addresses in the processor’s address space. A basic register definition is

#define GPIO_OUT (*(volatile uint32_t *)UINT32_C(0x40020014))

The integer constant is converted to a pointer, dereferenced, and treated as a volatile 32-bit object. The address and access width must match the device manual. Misaligned or unsupported accesses may cause a bus fault, and an incorrect address can modify an unrelated device.

Pointer arithmetic is scaled by the pointed-to type. If p is a uint32_t , then p + 1 advances by sizeof(uint32_t), normally four bytes on a target providing uint32_t. Byte-level address calculations should use uint8_t or an explicitly justified integer-address calculation.

3.1 volatile: purpose and limitations

A volatile-qualified access is an observable side effect in the C abstract machine. The compiler must perform accesses required by the program rather than replacing them indefinitely with a cached value. Typical uses include:

• memory-mapped peripheral registers;
• variables changed by an interrupt service routine (ISR) and observed by ordinary code;
• objects changed by hardware mechanisms such as DMA, subject to cache coherency rules.

static volatile bool conversion_done;

void ADC_IRQHandler(void)
{
    conversion_done = true;
}

volatile does not guarantee:

• atomicity of a multi-instruction operation;
• mutual exclusion between threads or interrupts;
• a hardware memory barrier;
• cache maintenance;
• a race-free program under the C memory model.

For shared state, use architecture-supported atomic operations, C atomics where supported and appropriate, brief critical sections, or an RTOS synchronization mechanism. Device memory ordering and compiler ordering are distinct issues; architecture-specific barriers may be required before enabling DMA, changing clock domains, or signaling another bus master.

3.2 const and pointer qualification

const prohibits modification through a particular lvalue; it does not necessarily mean the object resides in ROM.

A read-only hardware register may be represented as volatile const uint32_t. A write-only register might be represented as volatile uint32_t, because standard C has no write-only type. API design and access functions can impose stronger restrictions.

Casting away const and writing is undefined if the original object was defined as const. Placing lookup tables in nonvolatile memory also depends on the linker script and target architecture, not merely on the qualifier.

4. Structures, Layout, and Register Maps

Structures group related fields and can model consecutive registers:

typedef struct {
    volatile uint32_t MODER;      /* offset 0x00 */
    volatile uint32_t OTYPER;     /* offset 0x04 */
    volatile uint32_t OSPEEDR;    /* offset 0x08 */
    volatile uint32_t PUPDR;      /* offset 0x0C */
    volatile const uint32_t IDR;  /* offset 0x10 */
    volatile uint32_t ODR;        /* offset 0x14 */
} GpioRegs;

#define GPIOA ((GpioRegs *)UINT32_C(0x40020000))

_Static_assert(offsetof(GpioRegs, ODR) == 0x14u,
               "Unexpected GPIO layout");

Structure padding and alignment are implementation-defined within ABI constraints. Register overlays should therefore use fixed-width members, explicit reserved arrays where required, offsetof checks, and vendor-tested headers. Compiler-specific packing can cause inefficient or faulting unaligned accesses and should not be applied indiscriminately.

C bit-field allocation order, packing, and access width are implementation-defined. Bit fields can be convenient for private software state, but masks are generally safer for portable hardware access. A compiler may access a bit-field through a wider read-modify-write operation that conflicts with peripheral semantics.

For communication protocols and stored formats, do not transmit a C structure directly unless its representation is rigorously controlled. Padding, endianness, alignment, and versioning can differ. Serialize fields explicitly.

5. Startup Code: From Reset to main

At reset, the processor does not automatically execute the complete C language environment. Startup software establishes that environment. A typical sequence is:

1. obtain the initial stack pointer and reset-handler address from the vector table, where the architecture requires this;
2. configure essential processor state;
3. copy initialized writable data from its load address in flash to its runtime address in RAM;
4. zero the .bss section;
5. optionally configure clocks, memory protection, floating-point hardware, caches, and external memory;
6. run C/C++ runtime initialization, including constructors when applicable;
7. call main.

Figure: A typical startup path; exact steps depend on the processor and runtime.

A minimal byte-oriented initialization illustrates the linker/startup contract:

extern uint8_t __data_load_start;
extern uint8_t __data_start;
extern uint8_t __data_end;
extern uint8_t __bss_start;
extern uint8_t __bss_end;

void Reset_Handler(void)
{
    uint8_t *src = &__data_load_start;
    uint8_t *dst = &__data_start;

    while (dst < &__data_end) {
        *dst++ = *src++;
    }
    for (dst = &__bss_start; dst < &__bss_end; ++dst) {
        *dst = 0u;
    }

    SystemInit();
    __libc_init_array();
    (void)main();
    for (;;) { }
}

Production startup code must follow the toolchain ABI and device architecture. Copying by machine words can be faster but requires valid alignment and lengths. Watchdog handling, ECC RAM initialization, bootloader contracts, TrustZone state, and C++ constructors may add requirements.

6. Linker Scripts and the Memory Map

The compiler emits sections such as .text, .rodata, .data, and .bss. The linker script maps them into physical memory:

• .text: executable code, normally in flash;
• .rodata: read-only constants, normally in flash;
• .data: writable variables with nonzero initial values; stored initially in flash and copied to RAM;
• .bss: zero-initialized variables; allocated in RAM and zeroed at startup;
• stack and heap: RAM regions whose bounds must be intentionally managed.

A simplified GNU ld script is:

MEMORY
{
    FLASH (rx)  : ORIGIN = 0x08000000, LENGTH = 256K
    RAM   (rwx) : ORIGIN = 0x20000000, LENGTH = 64K
}

SECTIONS
{
    .text :
    {
        KEEP(*(.isr_vector))
        *(.text*)
        *(.rodata*)
    } > FLASH

    .data :
    {
        __data_start = .;
        *(.data*)
        __data_end = .;
    } > RAM AT> FLASH

    __data_load_start = LOADADDR(.data);

    .bss (NOLOAD) :
    {
        __bss_start = .;
        *(.bss*)
        *(COMMON)
        __bss_end = .;
    } > RAM
}

The .data output section has a virtual memory address (VMA) in RAM and a load memory address (LMA) in flash. In valid GNU ld syntax, the runtime region > RAM and load region AT> FLASH follow the section body. LOADADDR(.data) obtains the LMA used by startup code.

This pedagogical script omits alignment, exception tables, constructors, TLS, stack definitions, library sections, and assertions needed by many systems. A production script should be based on the device and toolchain specifications.

A map file reports section addresses, sizes, symbols, and library contributions. It is a host-side diagnostic report, not a programmable firmware image. Engineers use it to identify RAM pressure, unexpected library code, duplicate objects, and incorrect placement.

Worked Example 2: Static RAM budget

A device has 64 KiB of RAM. The map file reports .data = 3,072 bytes and .bss = 18,432 bytes. The design reserves an 8 KiB stack and a 4 KiB heap. Assuming these regions do not overlap and ignoring alignment losses,

With 1\text{ KiB}=1024\text{ bytes}, total RAM is 65,536 bytes. Therefore,

This is only a static budget. Actual stack depth, RTOS task stacks, DMA alignment, guard regions, and dynamic allocation fragmentation must also be assessed.

7. Hardware Abstraction and Driver Design

A hardware abstraction layer (HAL) separates application intent from register details. A maintainable design commonly uses these layers:

1. Register definitions: addresses, masks, and access types.
2. Low-level driver: clock enabling, initialization, status, and data transfer.
3. Board support package: maps logical functions such as STATUS_LED to pins and peripherals.
4. Service or middleware: buffering, protocols, storage, and scheduling.
5. Application: product behavior and control policy.

A narrow interface improves testability:

typedef enum {
    GPIO_OK = 0,
    GPIO_BAD_PIN,
    GPIO_BAD_MODE
} gpio_status_t;

gpio_status_t gpio_configure(gpio_pin_t pin, gpio_mode_t mode);
void gpio_write(gpio_pin_t pin, bool level);
bool gpio_read(gpio_pin_t pin);

Abstraction has costs: additional code, reduced access to specialized hardware, and possible runtime overhead. Static inline functions, compile-time configuration, and clear escape mechanisms can retain efficiency. The goal is not maximum layering; it is controlled coupling.

Drivers should define ownership, initialization order, valid call contexts, timeout behavior, concurrency policy, and error reporting. Blocking forever on a peripheral flag is rarely acceptable in a robust system.

8. Cross-Compilation and Build Artifacts

A typical pipeline is preprocessing → compilation → assembly → linking → image conversion. Important artifacts include:

An ELF file may be loaded by a debugger or converted to a deployment image. HEX or BIN files may be programmed depending on the tool and production process. A map file is never transferred as executable firmware.

Figure: The debug probe communicates with the target, while the logic analyzer independently observes target signals. The map file remains a host-side report.

For reproducibility, builds should record source revision, compiler version, flags, linker script, generated-code inputs, and dependency versions. Continuous integration should rebuild from a clean environment and archive hashes of released images.

9. Optimization and Correctness

Optimization may inline functions, remove dead code, reorder ordinary operations, fold constants, and allocate variables only to registers. Correct C code should preserve its required behavior across optimization levels, apart from implementation-defined timing and layout.

Debugging optimized firmware is harder because source statements may not correspond one-to-one with instructions. A variable may be unavailable, and execution may appear to jump between lines. This is not necessarily a debugger fault.

Useful practices include:

• enable warnings and treat selected warnings as errors;
• use static analysis and compiler sanitizers in host-side tests where applicable;
• inspect disassembly for critical startup, ISR, atomic, and timing code;
• avoid delay loops whose timing depends on optimization;
• measure worst-case stack usage and execution time;
• test at the intended release optimization level.

If a routine executes C processor cycles on a fixed-frequency core clock f_CPU, its ideal core execution time is

This relation excludes variable flash wait states, cache misses, interrupts, bus contention, DMA interference, and pipeline effects unless they are included in C. For example, 240 cycles at 48 MHz require an ideal 240/(48\times10⁶)=5\,\mu s. A GPIO pulse measured with a logic analyzer can test this timing in the complete system.

10. Debuggers, JTAG, SWD, Simulators, and Logic Analyzers

10.1 Source-level debugging

A debugger uses ELF symbols to relate machine addresses to source code. Through a debug probe, it can commonly halt and resume the processor, single-step, inspect registers and memory, set breakpoints, and program flash.

Software breakpoints replace an instruction with a trap and may be unsuitable in read-only memory. Hardware breakpoints use limited processor comparators. Watchpoints can halt on specified data accesses but are also limited resources.

Halting changes system behavior. Timers, communication peers, watchdogs, or motors may continue while the CPU is stopped. Some devices provide peripheral freeze controls, but these must be deliberately configured. Debugging a safety-related output requires a safe physical test environment.

10.2 JTAG and SWD

JTAG commonly uses several signals and may support boundary scan as well as core debugging. Serial Wire Debug (SWD), common on Arm microcontrollers, provides debug access using fewer primary signals. Neither interface is a logic analyzer: a debug probe interacts with the processor’s debug infrastructure, whereas a logic analyzer samples external electrical signals.

10.3 Simulators

A simulator can provide deterministic instruction execution, fault injection, and early testing without hardware. Its peripheral and timing models may be incomplete, however. It cannot automatically reproduce analog effects, clock tolerances, electromagnetic interference, metastability, or undocumented silicon behavior. Hardware validation remains necessary.

10.4 Logic analyzers

Logic analyzers sample digital signals and decode protocols such as UART, SPI, and I²C. They are valuable when firmware state appears correct but external timing is wrong. The selected sample rate must be sufficiently above the highest signal-transition rate to resolve edges and protocol timing; practical oversampling requirements depend on the instrument, signal quality, and decoder.

A sound diagnostic workflow is:

1. form a specific hypothesis;
2. identify internal state and external signals that can falsify it;
3. configure debugger and analyzer triggers;
4. capture without unnecessarily disturbing timing;
5. correlate signal timestamps with trace, logs, or GPIO instrumentation;
6. revise the hypothesis from evidence.

11. Applied Case: Intermittent SPI Sensor Failure

Background. This is an illustrative case. A battery-powered monitoring unit uses a 48 MHz microcontroller and an SPI accelerometer. Debug builds work, but optimized release builds occasionally return an invalid device identifier after wake-up.

Problem. Engineers initially suspect compiler optimization. The SPI driver polls a status register, controls chip select through GPIO, and uses DMA for later bulk transfers.

Analysis. The team examines the map file and confirms that the intended driver is linked and that RAM sections do not overlap. Disassembly shows that status polling still performs repeated loads because the register is volatile. A source debugger confirms the SPI peripheral is enabled. A logic analyzer independently monitors chip select, clock, and data. It reveals that the first clock edge occurs only 0.4 μs after chip select becomes active, while the sensor requires at least 1.0 μs. The unoptimized build happened to provide enough incidental delay.

A second problem appears during DMA operation: a buffer ownership flag is volatile, but buffer preparation and DMA start are not ordered according to the device’s bus requirements. Volatility alone is insufficient.

Approach and solution. The driver is changed to enforce the documented chip-select setup time using a hardware timer rather than an empty software loop. The API becomes a small state machine with explicit timeout and error states. Before DMA is enabled, the implementation performs the architecture-required memory ordering operation and any cache maintenance required by the selected MCU. Unit tests run against a mocked register interface, while hardware-in-the-loop tests measure timing at release optimization.

Outcome. Repeated wake-and-read testing shows compliant setup timing and no identifier failures. Continuous integration retains the timing test and checks that firmware size remains within budget.

Learning points. Optimization exposed a hidden timing dependency rather than creating arbitrary behavior. The debugger established internal configuration; the independently connected logic analyzer established external timing. Correctness came from meeting the sensor specification, not from disabling optimization or adding an unexplained volatile variable.

12. Reliability, Security, and Governance

Firmware can affect privacy, safety, property, and regulatory compliance. Engineering controls should include secure coding review, traceable requirements, controlled toolchains, and independent verification proportionate to risk.

Security-sensitive products should consider secure boot, signed updates, anti-rollback policy, debug-port lifecycle control, protected keys, and authenticated service access. Disabling JTAG or SWD can reduce attack surface but may impair servicing; the decision requires a documented threat model. Secret material should not be committed to source repositories or embedded as universal credentials.

Robust firmware validates pointers, lengths, states, and peripheral responses. It defines watchdog recovery, brownout behavior, update-failure recovery, and safe outputs after faults. Standards such as MISRA C, CERT C, IEC 61508, ISO 26262, IEC 62304, or sector-specific cybersecurity regulations may apply, but compliance with a coding standard alone does not establish system safety or security.

AI-assisted coding can generate boilerplate, tests, or register abstractions, but generated code may contain nonexistent registers, incorrect synchronization, license concerns, or insecure assumptions. It must undergo the same review, build, static analysis, target testing, and traceability process as human-written code.

13. Contemporary Practice and Best Practices

Modern development increasingly combines vendor configuration tools, open-source build systems, continuous integration, hardware-in-the-loop testing, static analysis, fuzzing of protocol parsers, and reproducible containerized toolchains. Rust and safer C subsets are gaining attention, but C remains dominant in many microcontroller ecosystems because of its mature compilers, libraries, and ABI integration.

Recommended practices are to:

• derive register definitions from authoritative device descriptions;
• use fixed-width unsigned types for register manipulation;
• isolate hardware access behind small, testable interfaces;
• document every use of volatile, critical sections, atomics, and barriers;
• keep startup code and linker scripts under version control;
• inspect map files and enforce section-size limits automatically;
• test release builds on target hardware;
• use debugger inspection and external measurement as complementary evidence;
• eliminate unexplained timing delays and unbounded polling;
• preserve release artifacts, tool versions, image hashes, and test results.

Chapter Summary

Embedded-C engineering spans the C language, processor architecture, peripheral semantics, startup runtime, linker placement, and physical measurement. Bit masks provide explicit register manipulation, while pointers and structures offer controlled access to memory-mapped devices. volatile preserves required accesses but does not provide atomicity, synchronization, barriers, or cache coherency. const controls modification through an interface but does not by itself determine physical placement.

Startup code copies .data, clears .bss, initializes the system, and enters main. The linker script establishes the relationship between flash load addresses and RAM runtime addresses; the map file reports that result but is not a programmable image. Hardware abstraction improves portability and testability when it preserves necessary device capabilities.

Cross-compilers, IDEs, simulators, debug probes, and logic analyzers answer different questions. JTAG/SWD exposes internal processor state, while a logic analyzer independently observes external signals. Reliable products result from correlating both forms of evidence, controlling the build environment, validating optimized firmware, and applying security and safety governance throughout development.

Key Terms

Cross-compiler: A compiler that runs on one platform and generates code for another.

Memory-mapped I/O: Peripheral access through addresses in the processor’s memory space.

Bit mask: A binary pattern used to select one or more bits.

Read-modify-write: An operation that reads a value, changes selected bits, and writes it back.

Volatile: A qualifier requiring program-specified accesses to an object to remain observable.

Const: A qualifier preventing modification through the qualified lvalue.

Atomicity: The property that an operation appears indivisible to competing execution contexts.

Memory barrier: An architecture-specific mechanism constraining memory-access ordering.

ABI: Rules governing binary interfaces, calling conventions, layout, and runtime behavior.

Vector table: A table containing reset and interrupt-handler information.

Startup code: Code that creates the C runtime environment before main.

Linker script: A file controlling section placement and symbol definition.

VMA: The address at which a section executes or is accessed at runtime.

LMA: The address from which a section is initially loaded.

ELF: A linked file format that can contain code, data, symbols, and debug information.

Map file: A linker-generated report of section and symbol placement.

HAL: A hardware abstraction layer separating applications from low-level device details.

JTAG/SWD: Hardware interfaces used for target programming and debugging.

Logic analyzer: An instrument that samples and analyzes external digital signals.

Watchpoint: A debug resource that detects specified memory accesses.

Review Questions

Short Answer Questions

1. Why are unsigned fixed-width types generally preferred for peripheral masks?
2. What does volatile guarantee, and what does it not guarantee?
3. Distinguish the VMA and LMA of an initialized .data section.
4. Why can C bit fields be unsafe for portable register access?
5. What information does a linker map file provide?

Long Answer Questions

1. Explain the complete path from C source code to an executing microcontroller image.
2. Discuss safe read-modify-write operations, including cases where they fail.
3. Explain a typical reset sequence and the contract between startup code and the linker script.
4. Compare simulators, source debuggers, JTAG/SWD probes, and logic analyzers.
5. Propose a layered HAL architecture and critically evaluate its costs and benefits.

Analytical / Application Questions

1. Design a safe C interface for a register containing normal configuration bits, a read-only status field, and write-one-to-clear interrupt flags.
2. A release build fails only with DMA enabled. Develop an evidence-based investigation plan involving qualification, ordering, cache behavior, debugger observations, and external measurements.
3. Given a device memory map and section-size report, construct a flash/RAM placement plan that includes startup copying, stack reservations, and overflow assertions.

Multiple Choice Questions with Answers

Question 1

Which declaration represents a pointer that may change but points to data that cannot be modified through that pointer?

A. uint8_t * const p

B. const uint8_t *p

C. uint8_t *p

D. const uint8_t * const p

Correct Answer: B. const uint8_t *p

Question 2

What is the principal reason for applying volatile to a memory-mapped status register?

A. To make every register operation atomic

B. To place the register in flash memory

C. To prevent required accesses from being optimized away

D. To insert a hardware memory barrier after each access

Correct Answer: C. To prevent required accesses from being optimized away

Question 3

Which GNU ld fragment correctly places .data at runtime in RAM while loading its initial contents from FLASH?

A. .data : { (.data) } > RAM AT> FLASH

B. .data : AT> FLASH { (.data) } > RAM

C. .data : { (.data) } > FLASH AT> RAM

D. .data : { (.data) } AT RAM > FLASH

Correct Answer: A. .data : { (.data) } > RAM AT> FLASH

Question 4

Which build artifact is primarily a host-side report rather than a target programming image?

A. Intel HEX file

B. Raw binary file

C. Linker map file

D. ELF executable

Correct Answer: C. Linker map file

Question 5

A 32-bit register field occupies bits 6–4. What positioned hexadecimal mask selects exactly this field?

A. 0x00000007

B. 0x00000038

C. 0x00000070

D. 0x000000E0

Correct Answer: C. 0x00000070

Question 6

Why is an ordinary read-modify-write operation potentially unsafe on a hardware register?

A. It always converts unsigned values to signed values

B. An interrupt or special register semantics may invalidate the read-back and rewrite

C. It prevents the linker from placing the register correctly

D. It can only operate on eight-bit registers

Correct Answer: B. An interrupt or special register semantics may invalidate the read-back and rewrite

Question 7

A routine requires 240 core cycles at a fixed 48 MHz clock, excluding stalls and interrupts. What is its ideal execution time?

A. 0.2 μs

B. 5 μs

C. 20 μs

D. 50 μs

Correct Answer: B. 5 μs

Question 8

Which tool independently observes target SPI clock, data, and chip-select waveforms?

A. Linker

B. Cross-compiler

C. Logic analyzer

D. Map-file parser

Correct Answer: C. Logic analyzer

Question 9

What is normally done to the .bss section during startup?

A. It is copied from RAM to flash

B. It is filled with random test data

C. It is zero-initialized in RAM

D. It is executed before the reset handler

Correct Answer: C. It is zero-initialized in RAM

Question 10

Why should a protocol packet generally not be transmitted by directly sending a C structure's memory representation?

A. Structures cannot contain integer members

B. Padding, alignment, and endianness may not match the protocol

C. Structure members are always volatile

D. Linkers remove structures from optimized programs

Correct Answer: B. Padding, alignment, and endianness may not match the protocol