DoorDash Staff Embedded Developer Interview Preparation Guide

Approach (short)
Use a log-structured, circular wear-leveling scheme with fixed-size pages and a small per-page metadata header stored on-flash. Minimize RAM by keeping only a compact active-pointer table in RAM.

Metadata (on-flash, per page/block)

• 16-bit sequence/version counter (monotonic wrap-safe)
• 8-bit state flags: ERASED, ACTIVE, VALID, MIGRATING
• 8-bit erase-cycle estimate (small saturating counter) — optional if space allows
• CRC16 of payload + header

Keep in-RAM: current write-tail index, cached header of current/next block (few bytes).

Erase scheduling & wear policy

• Write as append-only pages into blocks in a circular ring; mark old pages INVALID when superseded.
• Choose next erase candidate by scanning a small window (e.g., N blocks) and pick block with highest invalid ratio and lowest estimated cycles to balance wear. Use a simple cost = alpha*(invalid_ratio) - beta*(erase_count) to avoid hot/cold skew.
• Trigger GC when free pages < threshold; perform erase only on chosen candidate. Limit erases per cycle to avoid long latencies.

Power-loss mid-migration

• Use atomic two-phase commit with MIGRATING flag: when moving valid pages out, write new copies with new sequence, set MIGRATING bit on source block before finalizing. After all moved, write a ERASED marker (or increment block version) then erase.
• On boot scan: any block with MIGRATING counts as partially migrated — recover by treating pages with newer sequence as authoritative; if both exist, CRC and sequence resolve. If migration incomplete, resume migration or reclaim after verifying copies. Use CRC+sequence to ensure no torn writes.

Why this fits

• Append-only minimizes in-place writes and write amplification.
• Small on-flash header + tiny RAM state fits microcontroller constraints.
• Two-phase flags and CRC handle interrupted operations safely while balancing wear.

Answer (approach)

Use a single-producer (ISR)/single-consumer ring where only the ISR writes tail and only the main thread writes head. Make head/tail volatile uint16_t so compiler won’t optimize accesses. Require buffer size power-of-two and mask = size-1. Use compiler and CPU memory barriers around ownership handoff to ensure sample stores are visible before index publish.

Function signatures & implementation

#include <stdint.h>
#include <stdatomic.h>

#define RB_SIZE  256               // power of two
#define RB_MASK  (RB_SIZE - 1)

typedef struct {
    volatile uint16_t head;        // read by consumer, written by consumer
    volatile uint16_t tail;        // written by ISR, read by consumer
    uint16_t buf[RB_SIZE];         // sample type (change as needed)
} ringbuf_t;

/* Called from ISR: enqueue one sample, return 1 on success, 0 if full */
int rb_isr_enqueue(ringbuf_t *rb, uint16_t sample);

/* Called from main thread: dequeue one sample, return 1 on success, 0 if empty */
int rb_dequeue(ringbuf_t *rb, uint16_t *out);

// lightweight compiler barrier
static inline void comp_barrier(void) { atomic_signal_fence(memory_order_release); }

// Platform-specific full barrier (optional for strong ordering, e.g., ARM)
#ifndef PLATFORM_DMB
#define PLATFORM_DMB() do { /* insert CPU DMB if needed, e.g., __DMB(); */ } while(0)
#endif

int rb_isr_enqueue(ringbuf_t *rb, uint16_t sample) {
    uint16_t tail = rb->tail;
    uint16_t head = rb->head;            // read consumer head (volatile)
    if (((tail + 1) & RB_MASK) == (head & RB_MASK)) return 0; // full
    rb->buf[tail & RB_MASK] = sample;    // store data
    comp_barrier();                       // ensure data written before publish
    PLATFORM_DMB();
    rb->tail = (uint16_t)(tail + 1);     // publish to consumer
    return 1;
}

int rb_dequeue(ringbuf_t *rb, uint16_t *out) {
    uint16_t head = rb->head;
    uint16_t tail = rb->tail;            // read producer tail (volatile)
    if ((head & RB_MASK) == (tail & RB_MASK)) return 0; // empty
    *out = rb->buf[head & RB_MASK];      // read data
    comp_barrier();                       // ensure read before advancing head
    PLATFORM_DMB();
    rb->head = (uint16_t)(head + 1);     // consume
    return 1;
}

Explanation of barriers / volatile

• volatile prevents the compiler from caching head/tail in registers across ISR/main boundaries.
• atomic_signal_fence(memory_order_release) ensures compiler reorders around publish points are prevented.
• On weakly-ordered CPUs (ARMv7-M, etc.) add a CPU data memory barrier (DMB) before publishing to guarantee stores are globally visible to the consumer/ISR.
• No mutexes needed because ownership of indexes is partitioned: ISR only writes tail, main only writes head; both may read the other's index.

Edge cases & notes

• Use power-of-two RB_SIZE; mask simplifies modulo.
• Ensure head/tail are wide enough for wrap-around semantics (16-bit required).
• If sample write/reads are larger than atomic machine width consider additional synchronization.

Memory ordering is the order in which one core's loads and stores become visible to other cores and to devices. The order a core executes them in and the order others observe them can differ, because of store buffers (small queues that hold a core's writes before they reach cache), caches and out-of-order execution.

Strong versus weak

• Strongly ordered (x86, described by the x86-TSO model, "total store order"). "Strong" means few reorderings are allowed, not none. Each core has a store buffer, so a core's later load can complete before its own earlier store to a different address is visible to others. That is the single relaxation the x86-TSO model allows: stores from one core still become visible in the order they were written, which is why a data-then-flag publish works without extra instructions; cppreference notes that on x86 release/acquire ordering needs no extra CPU instructions, only the compiler is constrained. Code that publishes data and then a flag usually "just works" on x86, which hides bugs.
• Weakly ordered (Arm, Power). Unless you add ordering, the CPU may make independent loads and stores visible in any order. You buy ordering explicitly: acquire/release load and store instructions, or barrier instructions (on Arm, the data memory barrier family such as dmb, an instruction that stops memory operations on either side of it from being reordered past it; the Linux kernel hides them behind macros such as smp_wmb() and dma_wmb(), which are barriers for memory shared with devices; smp_wmb() is the write barrier for ordering between CPUs). Release/acquire loads and stores on Arm are the stlr (store-release) and ldar (load-acquire) instructions.

The language rule is the same on both: only std::atomic operations with memory_order_release / memory_order_acquire (or a barrier) create ordering. A relaxed atomic guarantees atomicity only (cppreference). volatile stops the compiler caching a value but emits no CPU barrier, so it does not fix either case below.

Case 1: inter-core flag and data

Producer writes data, then sets flag. Consumer waits for flag, then reads data. Without ordering, the consumer can see flag == 1 and a stale data. This kind of program is called a litmus test: a tiny program whose possible outcomes reveal what the memory model allows. This one tests it with one million fresh variable pairs, and the ready counter only keeps the two threads in step so that each round starts with the reader about to poll:

// Message passing litmus test: the writer publishes data, then a flag; the reader
// waits for the flag, then reads data. Each round is a fresh pair of variables.
#include <atomic>
#include <cstdio>
#include <thread>
#include <vector>
constexpr int N = 1000000;
static std::vector<std::atomic<int>> data(N), flag(N);

template <std::memory_order WR, std::memory_order RD>
long run() {
    for (int i = 0; i < N; ++i) { data[i].store(0, std::memory_order_relaxed); flag[i].store(0, std::memory_order_relaxed); }
    std::atomic<int> ready{-1};
    long bad = 0;
    std::thread w([&] {
        for (int i = 0; i < N; ++i) {
            while (ready.load(std::memory_order_acquire) < i) {}   // reader is about to poll round i
            data[i].store(1, std::memory_order_relaxed);
            flag[i].store(1, WR);
        }
    });
    std::thread r([&] {
        for (int i = 0; i < N; ++i) {
            ready.store(i, std::memory_order_release);
            while (flag[i].load(RD) == 0) {}
            if (data[i].load(std::memory_order_relaxed) == 0) ++bad;   // saw the flag, read stale data
        }
    });
    w.join(); r.join();
    return bad;
}
int main() {
    std::printf("relaxed store / relaxed load : %ld stale reads in %d rounds\n", run<std::memory_order_relaxed, std::memory_order_relaxed>(), N);
    std::printf("release store / acquire load : %ld stale reads in %d rounds\n", run<std::memory_order_release, std::memory_order_acquire>(), N);
}

Built and run in the gcc:14 image on aarch64 Linux (native, not emulated) with g++ -O2 -std=c++20 -pthread mp.cpp -o mp && ./mp, repeated runs print lines of this shape, where <N> is a small count that changes from run to run and is zero in some runs:

relaxed store / relaxed load : <N> stale reads in 1000000 rounds
release store / acquire load : 0 stale reads in 1000000 rounds

The relaxed variant shows stale reads only rarely (many runs print zero and others print a few), which is the typical weak-memory profile: it passes a unit test and fails in the field. The rate is not stable and depends on the host and its load. The release/acquire variant printed 0 in every run (its guarantee comes from the C++ memory model, not from those zeros). The compiler emitted stlr (store-release) and ldar (load-acquire) for the second variant (checked with g++ -O2 -S). The same program was also built with -fsanitize=thread: ThreadSanitizer printed no warning for the relaxed version, because relaxed atomics are not data races. A race detector does not report missing ordering between relaxed atomics (a plain, non-atomic payload behind a relaxed flag is different: ThreadSanitizer does report that as a data race). The runs were on Arm only; the x86 behaviour above comes from the cited model, not from a run.

Case 2: device-visible memory (DMA descriptors)

A DMA (direct memory access) engine reads a descriptor in RAM that holds a buffer pointer, a length and an "owned by device" bit. The driver fills the descriptor, sets the ownership bit, then writes a doorbell register to start the engine. If the ownership-bit store becomes visible before the payload fields, the device reads a half-written descriptor. The descriptor is the small record the device reads, and the doorbell is a device register that, when written, tells the engine to start. The Linux kernel's memory-barriers documentation shows the fix (the snippet below is that example with the kernel's explanatory comments omitted):

if (desc->status != DEVICE_OWN) {
        dma_rmb();
        read_data = desc->data;
        desc->data = write_data;
        dma_wmb();
        desc->status = DEVICE_OWN;
        writel(DESC_NOTIFY, doorbell);
}

Reading it line by line: the if checks that the device has handed the descriptor back (status is not DEVICE_OWN); dma_rmb() makes sure that check is complete before the CPU reads the descriptor's data; the next two lines read the old data and fill in the new; dma_wmb() makes sure those writes are visible before the next line; desc->status = DEVICE_OWN hands the descriptor to the device; and writel(DESC_NOTIFY, doorbell) is the kernel's write to a device register, here ringing the doorbell. The kernel's memory-barriers document explains the two barriers in these words: "The dma_rmb() allows us to guarantee that the device has released ownership before we read the data from the descriptor, and the dma_wmb() allows us to guarantee the data is written to the descriptor before the device can see it now has ownership." This snippet is reproduced from the kernel documentation and was not compiled or run, because it needs a kernel build environment and a device. On a microcontroller the same two rules apply with your platform's data-barrier intrinsic and the device manual's ordering rules for its bus.

The takeaway

Write for the weakest model you target. A missing barrier shows up as a stale read or a half-published object, rarely and only on the weak core, and when the shared data is itself atomic, as in the litmus test above, a race detector stays silent. Use release/acquire (or the kernel's barrier macros) at every publish point, and test on a weakly ordered CPU.

I would diagnose this in four layers: alignment, execution, incentives, and measurement.

First, alignment. I would check whether everyone still agrees on the problem statement and the target outcome. If different leaders define success differently, teams can stay busy without moving the business.

Second, execution. I would review what actually shipped, what was adopted, and where the process slowed down. Busy meetings and shipped deliverables do not prove value if the critical users never changed behavior.

Third, incentives. I would ask whether teams are rewarded for the new outcome or for protecting their own function. If a team is measured on local throughput, it may resist work that helps the overall initiative.

Fourth, measurement. I would compare leading indicators and lagging indicators. For example, if a support automation project shipped six features but ticket volume did not drop, I would look at adoption, usage, and customer behavior before calling it a success.

I would bring leadership a simple readout: what was intended, what changed, where the bottleneck is, and what evidence supports that conclusion. That gives leaders a choice between fixing alignment, adjusting incentives, or changing the plan.

For example, on a two-quarter initiative to reduce customer support ticket volume through a new self-service help center, the four-layer check found: alignment was actually fine, everyone agreed the goal was fewer repeat tickets, not just more help-center pageviews. Execution had shipped six planned articles and a new search widget on time. Incentives were fine too, the support team was measured on ticket deflection and had every reason to want the initiative to work. The real problem was measurement: the team had been reporting help-center pageviews as the success metric, which had gone up 3x, but nobody had checked whether the same customers who viewed an article still opened a ticket afterward. Pulling that number showed 71% of pageviews were followed by a ticket within 24 hours anyway, meaning the articles were being read but weren't actually answering the question. The recommendation to leadership was not to kill the initiative or blame the team, but to replace the pageview metric with a deflection rate (viewed an article and did not open a ticket) and to revise the two articles with the worst deflection rate. Leadership approved continuing the initiative under the corrected metric rather than shutting it down, and deflection rate became the standing measure for the next quarter.

Approach (brief)
I2C register-read with a repeated START writes the target register address to the slave, then without STOP issues a repeated START and reads N bytes. This preserves bus control and avoids other masters intervening.

Pseudo-transaction
START
slave_addr + W (7-bit addr <<1 | 0) ; ACK/NACK
reg_addr_byte(s) ; ACK after each
REPEATED START
slave_addr + R (7-bit addr <<1 | 1) ; ACK/NACK
data0 -> master sends ACK (if more bytes expected)
data1 -> master sends ACK
...
dataN-1 -> master sends NACK (last byte)
STOP

Notes on ACK/NACK

• Master issues ACK after every received byte except the final one, where it sends NACK to signal end-of-read.

Error handling

• If slave NACKs after slave_addr+W or after reg_addr byte: abort, issue STOP, optionally retry with backoff; check wiring, pull-ups, and device power/state.
• If slave NACKs to repeated-start address+R: issue STOP, retry or report device not responding.
• If NACK occurs during data transfer unexpectedly: send STOP, optionally reset bus (clock pulses + STOP), increment error counter, and retry limited times. Log and escalate if persistent.

Direct answer

Don't try to average everyone's position into a compromise nobody's happy with. Ground the negotiation in the shared outcome, make the trade-offs between options explicit with evidence, and force a real decision (with an owner and a documented rationale) within a fixed timeframe. A compromise sticks when people can see why it was chosen, not just that it split the difference.

Structured elaboration

1. Reframe around outcome, not position. Ask each stakeholder what success looks like for them, not what they want built. Two stakeholders who seem opposed on the "what" often agree on the "why," which is where the real compromise lives.
2. Bring evidence, not opinions. Gather whatever is available and relevant: usage data, cost/effort estimates, prior incidents, qualitative feedback. A room full of opinions negotiates forever; a room with a shared set of facts converges faster.
3. Make trade-offs visible. Lay out 2-3 real options with their costs and benefits side by side, instead of a single proposal to accept or reject. People compromise more easily when they're choosing between concrete alternatives than when they're being asked to give up a specific ask.
4. Use a structured negotiation move. Propose a balanced default option first, then invite each side to request a bounded concession from it, rather than starting from each side's maximal ask and negotiating down. Time-box the discussion so it doesn't drift into re-litigating the same points.
5. Document the decision and name an owner. Write down what was decided, why, who owns it, and when it will be revisited. If the group truly can't converge, escalate with a specific recommendation rather than an open question, so the escalation itself doesn't become another unresolved debate.
6. Build in a review point. Treat the agreement as provisional and testable, not permanent. A short follow-up (after the next milestone, or a fixed number of weeks) to check whether the compromise is actually working keeps people bought in because they know it isn't final and unappealable.

Worked example

Three stakeholders disagree on scope for a feature: one wants the full version shipped now, one wants it deferred a quarter, one wants a stripped-down version shipped immediately. Instead of negotiating "how much scope," the facilitator asks each what outcome they're protecting: the first is protecting a customer commitment, the second is protecting engineering capacity for other work, the third is protecting the team's ability to learn before over-investing. That reframing surfaces a real option none of them had proposed: ship a narrow version that satisfies the customer commitment, explicitly scoped as a first iteration, with the deferred work logged and re-prioritized at the next planning cycle. The decision, the scope boundary, and the re-prioritization date are written down and shared with all three stakeholders.

Trade-offs & pitfalls

• Pitfall: false compromise, where everyone gets a token piece of what they asked for and the result satisfies no one's actual underlying need.
• Pitfall: skipping documentation. An undocumented "agreement" gets re-argued the moment someone's memory of it differs.
• Pitfall: treating consensus as required. Some decisions need a single accountable owner to make the call after input, not unanimous agreement, especially under a deadline.
• Senior differentiator: designing the forcing function (a default option, a timebox, a named decision owner) instead of facilitating an open-ended discussion indefinitely. That's what turns "several people who each want something different" into an actual decision.

Approach

• Use initial two-step calibration: coarse (measure offset vs true time) then temperature sweep to characterize frequency vs temperature.
• Store calibration coefficients (ppm offset, temp coefficient, polynomial) in NVM.
• At each wake compute corrected sleep interval to hit target wall-clock time, compensating for predicted RTC drift and temperature-dependent error. Periodically re-calibrate.

Pseudocode (C-style)

// NVM structure
typedef struct { int32_t ppm_offset; int32_t ppm_per_degC; int32_t ref_temp_mC; uint32_t crc; } rtc_cal_t;

// Read/write NVM helpers (platform-specific)
rtc_cal_t read_cal_from_nvm(void);
void write_cal_to_nvm(rtc_cal_t *cal);

// Convert ppm to fractional seconds per day: seconds_error = ppm * 86400 / 1e6
static double ppm_to_seconds_per_day(int32_t ppm){ return (double)ppm * 86400.0 / 1e6; }

// Initial calibration (run during manufacturing / first boot)
void initial_calibration(void){
  // 1) coarse: compare RTC to reference (NTP / GPS) over window
  int64_t ref_start = get_ref_time();
  int64_t rtc_start = rtc_read_seconds();
  sleep_ms(60000); // measure over 60s or longer
  int64_t ref_end = get_ref_time();
  int64_t rtc_end = rtc_read_seconds();
  double error_s = (rtc_end - rtc_start) - (ref_end - ref_start);
  int32_t ppm_offset = (int32_t)(error_s * 1e6 / (ref_end - ref_start));

  // 2) temperature sweep (simple two-point)
  int32_t t1 = read_temp_mC();
  int64_t rtc_measure_start = rtc_read_ticks();
  sleep_ms(300000); // 5 minutes at temp t1
  int64_t rtc_measure_end = rtc_read_ticks();
  double freq_err1_ppm = measure_ppm_from_ticks(rtc_measure_start, rtc_measure_end);
  // change temperature physically or use environment; measure freq_err2_ppm at t2
  int32_t t2 = read_temp_mC();
  double freq_err2_ppm = /* measured */;
  int32_t ppm_per_degC = (int32_t)((freq_err2_ppm - freq_err1_ppm) * 1000 / (t2 - t1)); // ppm per mC scaled

  rtc_cal_t cal = { ppm_offset, ppm_per_degC, /*ref_temp_mC=*/t1, compute_crc(...) };
  write_cal_to_nvm(&cal);
}

// Compute corrected sleep seconds to wake at target_wallclock (HH:MM:SS)
uint32_t compute_sleep_seconds(int target_wday, int target_h, int target_m, int target_s){
  rtc_cal_t cal = read_cal_from_nvm();
  int32_t cur_temp_mC = read_temp_mC();
  // predicted ppm = base + coeff * (T - ref)
  int32_t deltaT_mC = cur_temp_mC - cal.ref_temp_mC;
  int32_t predicted_ppm = cal.ppm_offset + (cal.ppm_per_degC * deltaT_mC) / 1000;
  // compute seconds until target wallclock according to RTC wall time
  int64_t now = rtc_read_time(); // seconds since epoch
  int64_t target = compute_next_target_epoch(now, target_h, target_m, target_s);
  double nominal_sleep = (double)(target - now);
  // compensate: actual drift during sleep approx = nominal_sleep * predicted_ppm / 1e6
  double adj_sleep = nominal_sleep - nominal_sleep * (double)predicted_ppm / 1e6;
  // clamp to safe bounds
  if(adj_sleep < 1.0) adj_sleep = 1.0;
  if(adj_sleep > 7*24*3600) adj_sleep = 7*24*3600;
  return (uint32_t)(adj_sleep + 0.5);
}

// Daily wake handler
void daily_wake_handler(void){
  // perform task, maybe sync to reference occasionally
  if(need_resync()){ // e.g., monthly or after large error
    initial_calibration(); // or a lighter re-calibration routine
  }
  uint32_t sleep_s = compute_sleep_seconds(/*daily*/0, 7,0,0); // example target 07:00:00
  rtc_sleep_seconds(sleep_s);
}

Key concepts & reasoning

• Model uses linear ppm + temp coefficient (sufficient for many crystals). Store in NVM for persistence.
• Predict error during sleep and shorten/lengthen sleep to hit wall-clock.
• Periodic re-calibration corrects long-term aging and non-linearities.
• Clamp bounds to avoid extreme sleep times and ensure safety.

Edge cases & improvements

• Use higher-order polynomial if oscillator shows non-linear temp response.
• Fuse-in real reference (NTP/GPS) when available for autonomous correction.
• Add CRC and versioning to NVM; protect against power loss during writes.

Definition

DMA (Direct Memory Access) is a hardware peripheral that moves data directly between memory and another peripheral, or between two memory locations, without the CPU executing a copy loop. The CPU sets up a transfer, source, destination, length, and the DMA controller moves the data independently, freeing the CPU to do other work or sleep, typically firing an interrupt when done.

When to choose DMA over CPU-driven copy

Any large or frequent data movement where CPU cycles would otherwise be tied up in a copy loop. The classic case is streaming to or from a peripheral, UART, SPI, an ADC sampling stream, an audio codec, where CPU-driven byte-by-byte handling either burns a lot of cycles directly or spends a disproportionate amount of time in per-byte interrupt overhead. DMA turns that into one setup call and one completion interrupt for the whole buffer.

Setup latency

Configuring a transfer, programming source, destination, length, and channel registers, has fixed overhead. For a very small, one-off transfer, a handful of bytes, that setup cost can exceed just doing the copy on the CPU directly. DMA wins on volume, not necessarily on latency for tiny transfers.

Minimum transfer size and alignment

Many DMA controllers require source and destination addresses to be aligned to a boundary (word-aligned, for instance) and may have a minimum burst size for efficiency. An unaligned or oddly sized transfer either isn't supported directly or falls back to a slower single-beat mode, worth checking the specific peripheral's datasheet before assuming DMA works unmodified for any buffer shape.

Cache interactions and coherency

On parts with a data cache, DMA moves data directly in physical memory, bypassing the CPU's cache. If the CPU has cached data that DMA is about to overwrite, or the CPU reads a buffer DMA just wrote without invalidating its cache first, the result is stale or incoherent data. This needs explicit cache maintenance, clean the cache before a DMA read of CPU-written data, invalidate it before the CPU reads DMA-written data, that has no equivalent on CPU-driven copies, where the cache stays naturally coherent through the CPU's own loads and stores.

When DMA adds more overhead than benefit

Very small or infrequent transfers, where setup cost dominates; transfers that need per-byte processing anyway, if the CPU has to touch every byte regardless (parsing or validating as it goes), DMA's "CPU doesn't touch it" benefit is moot; and systems tight on DMA channels, where contention between peripherals can serialize transfers expected to run concurrently, sometimes costing more real time than a simpler CPU-driven approach on a particular workload.

Clarify requirements

• Target: dual-core MCU (M4 application + M0 peripheral/control). Need multi-core debug, avoid deadlocks, view shared RAM coherently, and fix/prevent peripheral ownership races.

Attach debugger

• Use a multi-core-aware debug probe (SEGGER J-Link, ST-Link) and IDE that supports multicore (Ozone, STM32CubeIDE).
• Configure two debug sessions (one per core) or a single multi-core session; ensure correct target core selection and reset strategy (halt on connect vs run).

Safe pause / resume

• Always pause cores in a defined order: halt the core that owns peripherals first (M0), then halt the application core (M4). On resume, start M4 then M0.
• Prefer cooperative pause via a handshake: set a “debug-request” flag in RAM and wait for core to acknowledge idle state before halting — avoids halting while holding locks or peripherals.
• Avoid breakpoints inside critical sections or ISR handlers that hold hardware resources; use breakpoints outside locks or single-step carefully.

Inspect shared memory coherently

• Be aware of caches: flush/invalidate DCache before/after reading shared regions or halt the core owning cache. Use CPU data memory barriers (DMB/DCCMVAC) in code.
• If both cores can run, read coherent copies: implement sequence numbers or versioned buffers (double-buffering + sequence counters) to detect torn reads.
• When halted, prefer halting both cores or the owner core to get a consistent snapshot.

Debug a race on peripheral ownership

• Reproduce with core-specific logging (timestamps) and toggle a debug GPIO on ownership change. Use watchpoints on ownership register or semaphore to break on change.
• Single-step the acquisition path while observing peripheral enable bits and interrupt masks. Add assertions that fail early if ownership is ambiguous.

Synchronization primitives / HW semaphores

• Prefer hardware semaphores (e.g., STM32 HSEM) for peripheral arbitration — atomic, low-latency.
• Software: use atomic compare-and-swap for an ownership register, spinlock with backoff, or mutex/message-passing depending on latency constraints.
• For low-power/real-time: use hardware mailbox or event flags to hand off ownership, combined with interrupt-based notification to avoid busy-waiting.

Trade-offs: HW semaphores are simplest and safest; software locks are flexible but require careful cache/coherency handling and deadlock design (always acquire in same order, keep critical regions short).

Brief description
Dual-partition A/B uses two firmware slots (A and B). The device runs from one slot while the other is updated, enabling atomic swaps and rollback if the new image fails.

Typical partition layout

• Bootloader (ROM/primary boot stage)
• Partition table / A/B metadata (flags, active slot, version, checksums)
• Boot partition A (kernel + rootfs / firmware image)
• Boot partition B (same layout as A)
• Data / persistent storage

How bootloader chooses a partition

• Read A/B metadata: active_slot, successful_flag, boot_count, checksum/state
• If active_slot marked successful → boot that slot
• If previous boot failed and boot_count < threshold → mark candidate as untested and try alternate
• Verify checksum/signature before handing control; else fallback

How updates are written

• Write new firmware to the inactive slot (e.g., B if running A)
• Verify integrity (hash/signature) after write
• Update metadata to mark inactive as “pending” with boot_count = 0
• Do not alter active slot until new image is proven

Safe switch / rollback

• Bootloader attempts new slot and increments boot_count
• User-space or init sends a “mark successful” to metadata after health checks (services up, watchdog cleared)
• If successful_flag set within threshold, bootloader marks new slot as active and clears previous
• If boot_count exceeds threshold or integrity/health checks fail, bootloader rolls back to previous known-good slot automatically
• Use hardware watchdog and atomic metadata updates to avoid bricking

Notes / best practices

• Use signed images, atomic writes for metadata, small boot_count window (e.g., 3 boots)
• Keep persistent state separate or use migration logic
• Example implementations: Android A/B, RAUC, SWUpdate patterns commonly used in embedded systems.