Hardware Simulation, Emulation, and Debugging Questions

Approach summary
I would instrument the bus with a logic analyzer (e.g., Saleae) to capture many transactions and correlate failures with timing/state anomalies.

Trigger & capture setup

• Use a Start condition trigger (SDA falling while SCL high) to capture from the first bit; also set a Stop trigger (SDA rising while SCL high) for full frames.
• Capture several seconds or thousands of transfers (use streaming or large buffer) to catch intermittent failures.
• Record both SDA and SCL and any MCU interrupt line or RESET if available to correlate events.

Sample rate

• Use ≥4× SCL frequency as a minimum; 10–20× is safer. For 400 kHz I2C use ≥4 MHz; for 100 kHz use ≥1 MHz. Higher rates (≥8–16 MHz) help visualize edge timing and glitches.

Decoding & identifying NACKs / clock-stretching

• Run the protocol decoder (Saleae I2C decoder). NACK is indicated by ACK bit = 1 after an 8-bit byte. Manually inspect ACK/NACK bits if needed.
• Clock stretching: look for SCL being held low by the slave longer than master drives it — decoder may show SCL low intervals longer than tLOW. Also detect SCL low while master expects to drive it high (SDA/SCL direction from traces).
• Look for SDA toggles during SCL high (invalid) or bus arbitration losses (multiple masters).

Timing comparison with datasheet

• Measure SCL high/low durations, SDA setup (data stable tSU;DAT before rising edge) and hold (tHD;DAT after falling edge), start/stop setup times. Put each measured value alongside datasheet min/max.
• Use the analyzer’s cursor delta to get exact ns/µs and flag violations (e.g., tSU;STA too short, tHD;STA too short, tHD;DAT violations).

Interpreting failure patterns

• Repeated NACK on address only: wrong slave address, slave not powered, or slave state machine not ready.
• Sporadic NACKs on data bytes: buffer overrun in slave, timing violation, or noisy data lines.
• Frequent long SCL low (clock-stretch): slave is processing; firmware/interrupt blocking on MCU or slave-side overload.
• Glitches, extra edges, or spurious START/STOP: poor pull-ups, ringing, long traces, or EMI.
• Arbitration lost / mixed ACKs: multiple masters or drivers fighting the bus.

Actions after capture

• Fixable issues: adjust pull-up strength, add series resistors, shorten traces, increase sample/stable timing, add retry logic.
• If clock-stretching observed, modify firmware to tolerate it or investigate slave workload.
• If timing violates datasheet, slow down I2C master clock or change driver timing.

This workflow yields objective evidence (decoded frames + timing deltas) to pinpoint whether failures are protocol-level (NACKs), electrical (glitches/pull-ups), or timing/firmware issues.

Approach (what I do first)

• Connect via SWD/JTAG and start OpenOCD, then connect GDB to the target. I first try a halted reset to stop in early boot:

openocd -f interface/stlink.cfg -f target/stm32f4x.cfg
# in gdb:
target remote :3333
monitor reset halt

• If firmware crashes before main, enable vector catch or set a breakpoint at Reset_Handler or HardFault_Handler:

monitor arm vector_catch reset

Why this helps

• Reset/halt stops CPU before executing problematic code so I can inspect registers, stack pointer, and vector table.
• If execution immediately faults, I read fault status registers (CFSR/ HFSR) to identify cause and view stacked PC to see faulting instruction.

Software vs Hardware breakpoints

• Software breakpoints overwrite instruction memory with a trap (e.g., BKPT) — cheap and unlimited but require writable memory (RAM/flash writable area).
• Hardware breakpoints use the CPU’s debug unit to watch addresses without modifying code — limited in number (typically 2–8) but work anywhere, including flash and ROM.

Why breakpoints in flash can fail

• On some MCUs flash isn’t readable/executable while being programmed/erased; inserting a software breakpoint requires writing flash, which isn’t allowed at runtime.
• Also, if the MCU fetches instructions from flash via a prefetch/cache or executes from a mirrored region, replacing an instruction in flash may not take effect. Thus software breakpoints often fail in flash; hardware breakpoints are required for early-boot or protected flash regions.

Practical tips

• Use hardware breakpoints for Reset_Handler/ISRs.
• If you run out of hardware breakpoints, set a single early hardware bp then change program counter to a RAM routine that sets software breakpoints or semihosting for deeper inspection.

Overview
Practical techniques split into development-time (prevent/sizing) and runtime (detect/mitigate). Below are methods, examples, and tradeoffs for resource-constrained MCUs.

Development-time

• Static stack analysis / worst-case stack usage (WCSU)
  • Use stack-depth analysis tools or manual frame accounting per function (including interrupts, context switches).
  • Example: annotate recursive calls and eliminate or bound recursion.
• Static sizing with safety margin
  • Sum max call depths + ISR stacks + RTOS task stacks; add 10–30% margin.
• Linker-script adjustments
  • Place stacks in dedicated RAM regions; align and reserve guard areas via linker symbols (e.g., __stack_start, __stack_end).
  • Example: reserve a small .noinit region to preserve stack fill across resets for post-mortem.

Runtime

• Stack canaries / overflow checks
  • Write a sentinel at task entry or function prologue and verify on context switch/return. Low overhead if checked on task switch.
• Stack coloring / pattern-fill
  • Fill stack with known pattern at init; measure high-water mark to tune sizes.
• MPU guard regions
  • Configure MPU to make an unmapped/readonly page below stack so overflows trigger fault.
• Periodic or context-switch checks
  • Check canary/pattern only on task switch or watchdog window to reduce overhead.

Trade-offs (MCUs)

• Flash/RAM cost: canaries and pattern-fill are cheap; full runtime instrumentation or frequent checks cost CPU cycles and RAM.
• MPU requires MMU/MPU support and increases complexity (some Cortex-M have MPU; small 8-bit MCUs don’t).
• Static analysis is cheapest runtime-cost but depends on tooling and conservative estimates may waste RAM.
• Balanced approach: use static sizing informed by pattern-fill measurements, add MPU guard where available, and simple canary checks at task switches.

Overview / goals
Verify read-clear (RC) and interrupt behavior end-to-end: registers auto-clear on read, interrupts asserted/cleared correctly, driver reacts to races and lost/duplicated events.

Environment & approach

• Use QEMU device model (C) or SysBus device to emulate registers; expose chardev/semantics to guest.
• Use QEMU monitor/TCP chardev to inject register values and pulses; use virtual IRQ lines to toggle interrupts.
• Drive guest-side driver under test in a small test harness (userspace test process or RTOS task) that performs reads/writes and reports state via serial/log.

Fault injection & concurrency

• Inject faults via QEMU: set register bits asynchronously (timer callbacks), toggle IRQ lines, drop or coalesce IRQ pulses.
• Simulate concurrent events: spawn multiple QEMU timers that write the same RC register at near-same timestamps to reproduce race windows. Also use guest multi-threaded tests that read while interrupts occur.
• Fuzzing: randomize set/clear timing and bit patterns to find edge cases.

Assertions & test types

• Unit tests (host/driver level): mock register map in C using a fake hw abstraction; assert read causes clear, double-read returns 0, ISR path sets expected state. Fast, deterministic.
• Integration tests (QEMU+guest): boot test image that runs driver tests; collect serial JSON results. Scenarios: single event, burst events, lost IRQ, spurious IRQ, concurrent reads. Use timestamps to assert ordering and latency bounds.
• Regression CI: run unit tests on every commit; run integration QEMU tests in pipeline (matrix: with/without KVM, different CPU speed). Add nightly stress/fuzz runs; fail build on assertion or increased flakiness.

Instrumentation & reliability

• Add deterministic seeds, logging of register timestamps, and counters for IRQs asserted/handled.
• Use tracepoints (ftrace or QEMU logging) and automated diffing of traces.
• For flaky scenarios, capture QEMU snapshots on failure and enable gdb for post-mortem.

Metrics & acceptance

• Tests must cover: RC semantics, ISR correctness, missed-IRQ detection, no-double-handling, and timing regression (latency). Gates: zero regressions, <1% flaky rate, reproducible failure capture.

Approach summary
I’d pick a lightweight C unit test framework (Unity/CMock combo) and incrementally introduce tests by isolating logic from hardware, using mocks/fakes for peripherals, deciding host vs on-target runs by test type, and gating CI to run fast host tests on every commit and on-target smoke tests nightly or per merge.

Framework selection

• Choose Unity for pure C, small footprint; add CMock for automated mock generation of HAL interfaces.
• Criteria: small runtime, active community, integrates with CMake/Make and IDEs, supports test runners for host and target.

Hardware abstraction

• Create clear HAL interfaces (header-only) that expose behaviors, e.g. gpio.h, spi.h.
• Keep business logic device-independent: firmware.c calls hal functions only.
• Example interface:

// gpio.h
typedef enum { GPIO_LOW, GPIO_HIGH } gpio_level_t;
void gpio_write(int pin, gpio_level_t level);
gpio_level_t gpio_read(int pin);

Mocks and fakes

• Use CMock to auto-generate mocks for hal headers for host-unit tests.
• Implement lightweight software fakes for subsystems (e.g., timer tick simulator, fake ADC) used in integration tests on host.
• On-target, use hardware-in-the-loop (HIL) drivers or shim that routes mock hooks to test harness.

Host vs on-target tests

• Host: pure logic units, timing-insensitive code, use CMock/fakes. Fast, run on CI per commit.
• On-target: hardware-dependent, timing-critical, concurrency/ISR behavior. Run on-device probes or QEMU; run in CI nightly or on PR merge.

CI integration

• Stage 1 (PR): build and run host-unit tests with coverage; fail fast on regressions.
• Stage 2 (merge): deploy firmware to test rigs (e.g., Raspberry Pi/JTAG + DUT farm) to run on-target smoke/integration tests; collect logs and return pass/fail.
• Use artifact caching, test matrix (compiler flags, optimization levels), and require coverage threshold.

Trade-offs & metrics

• Start with 70/30 host/on-target split, increase host coverage first. Monitor test runtime, flaky test rate, and code coverage to measure progress.

This approach gives fast feedback, keeps hardware decoupled, and prevents regressions while respecting embedded constraints.