Hardware/Software Co-Design and Resource Constraints Questions

Design summary

• Single DMA producer (writes contiguous chunks ≤ N), single CPU consumer.
• Power-of-two buffer allows mask-based wrap.
• DMA must never be given a write region that would overrun unread data; CPU maintains a read pointer (r) and exposes it to check free space. DMA uses a write pointer (w) updated by CPU-visible register after a transfer completes (or via hardware when supported).
• Use 32-bit indices that wrap naturally; buffer index = idx & (size-1).

Types & prototypes

#include <stdint.h>
typedef struct {
    uint8_t *buf;
    uint32_t size;    // power of two
    uint32_t mask;    // size - 1
    volatile uint32_t dma_write_idx; // updated by DMA (hardware or after transfer)
    volatile uint32_t cpu_read_idx;  // updated by CPU when data consumed
} circ_buf_t;

// Called by init code to configure DMA to start a transfer to &buf[offset]
int circ_buf_request_dma_write(circ_buf_t *c, uint32_t bytes);

// CPU reads available bytes
uint32_t circ_buf_bytes_available(circ_buf_t *c);

// CPU consumes n bytes (advance read index)
void circ_buf_consume(circ_buf_t *c, uint32_t n);

Pointer management

• Producer (DMA): DMA writes to physical buffer at offset = dma_write_idx & mask. Before starting a transfer of length L, driver checks free = size - (dma_write_idx - cpu_read_idx); require L <= free. After DMA completes, hardware or ISR atomically increments dma_write_idx by L (use 32-bit increment; no locks).
• Consumer (CPU): Reads dma_write_idx (must read volatile), computes available = dma_write_idx - cpu_read_idx. Read up to available or split across wrap using mask. After processing, update cpu_read_idx by consumed bytes.

Cache maintenance

• If D-cache is present and DMA bypasses cache:
  • Before DMA write: clean/flush cache lines for target buffer region (so RAM is updated if CPU had dirty lines).
  • After DMA write completes: invalidate cache lines covering the written region before CPU reads.
• Use aligned line-size operations; perform maintenance only for the specific region(s) the DMA will touch to minimize overhead.

Minimize CPU overhead

• Let DMA transfer max contiguous chunk up to N but limited so it won't wrap across unread data; prefer configuring DMA to a single contiguous region (may split at wrap boundary).
• Use 32-bit indices and mask arithmetic; avoid atomics beyond volatile 32-bit reads/writes.
• Use DMA-complete IRQ sparingly or use hardware that can chain transfers; if possible use peripheral pointers to update dma_write_idx in hardware to avoid ISR.

Edge cases

• Ensure bytes requested never exceed buffer capacity minus one full packet of unread data.
• Handle wrap by splitting DMA into two descriptors: to end-of-buffer and from start.
• Use memory barriers if CPU/arch reorder reads/writes.

Approach summary
Meet 50 ms detection and <5 µA standby by shifting sensing/decision into always-on, ultra-low-power hardware (sensor interrupt or low-power co‑processor) and keeping the main MCU asleep except for brief, infrequent wakeups.

Hardware strategies

• Use sensors with built-in interrupt/comparator (motion, touch, capacitive) so they assert an OUT pin only on relevant events; the sensor can filter/debounce to reduce false wakes.
• Choose a PM MCU with interrupt-capable GPIOs that can wake from deep sleep in <50 ms (check wake-from-external-interrupt + boot time).
• Add an ultra-low-power co-processor / ULP core (or low-power timer + analog comparator) to perform simple sampling/threshold detection while MCU sleeps.
• Use RTC for scheduled wakeups or long-term housekeeping; keep RTC in low-power domain.

Firmware strategies

• Configure sensor-side interrupt to trigger directly to MCU EXTI or to ULP. If routed to ULP, implement event validation there and only escalate to main MCU when confirmed.
• Keep ISR minimal: capture timestamp, store event metadata (via DMA if supported), and schedule deferred processing in main loop.
• Duty-cycle only when necessary: let ULP sample at high rate during expected-active windows, lower rate otherwise.
• Use hysteresis, adaptive thresholds, and event batching to reduce false positives and wake frequency.
• Measure end-to-end latency (sensor detection → ISR → application) and tune sampling/clock domains.

Trade-offs to negotiate

• Cost vs power: adding an external low-power coprocessor or smarter sensor increases BOM but reduces MCU wakeups and overall energy.
• Complexity vs robustness: sensor-side processing reduces MCU load but moves logic to hardware/firmware that’s harder to update; negotiate firmware update mechanism or choose programmable ULP.
• Latency margin vs standby current: faster MCU wake/resume reduces latency but may increase standby leakage; prefer sensor interrupts and ULP to avoid frequent full wakes.
• Testability and debugging effort: ask for evaluation boards/signal access to validate wake timing and current budgets.

Key checks

• Validate worst-case wake latency (<50 ms) including debouncing and OS scheduler delays.
• Verify standby current with all peripherals in target states (<5 µA).
• Instrument with oscilloscopes/power profiler and iterate thresholds/patterns.

Approach overview
I’d design firmware so a single image supports many board revisions and optional peripherals via a combination of runtime descriptors, modular drivers, and selective compile-time guards to minimize build/test explosion.

Board descriptors & runtime capability table

• Store a compact board descriptor (device-tree blob or JSON) in flash/EEPROM populated at build or detected at boot (CRC + version).
• On boot parse descriptor into a runtime capability table: peripherals present, pinmux, power domains, quirks, and revision IDs.
• Drivers consult the capability table to probe/register devices dynamically.

Modular drivers & interfaces

• Implement drivers as self-contained modules with clear HAL-layer interfaces and well-defined init/probe/uninit hooks.
• Use a peripheral registry: drivers register probe functions that run only when capability table indicates presence.

Compile-time guards

• Keep heavy compile-time guards for resource-limited targets or when excluding large subsystems (e.g., optional mesh stack). Prefer runtime enablement; use Kconfig-style options for major features to avoid bloated images.

CI and test strategy

• CI builds a full-feature image and a minimal image; unit tests compile drivers with mocked capability tables.
• Use hardware-in-loop matrix sampling: test canonical board revisions and use hardware labs + automated acceptance tests that load simulated descriptors for others.
• Regression tests exercise probe paths and quirk branches.

Deprecation & migration

• Tag deprecated features in descriptors, emit warnings at boot, and map legacy IDs to compatibility layers in software.
• Provide migration shims: keep old driver paths for N releases, log telemetry to identify active legacy usage, and schedule removal based on telemetry and time.

This balances single-image maintainability, runtime flexibility, and CI cost while allowing safe deprecation and controlled feature removal.

Clarify constraints & goal

• Device: 256 KB flash, 32 KB RAM, intermittent network, frequent power loss.
• Goal: Secure, power-loss-resilient OTA with anti-rollback and low RAM/flash footprint.

Partitioning

• Prefer single primary slot + small recovery slot (hybrid A/B):
  • Primary active image (~200 KB), Recovery minimal bootloader/rescue image (~32 KB).
  • Rationale: Full A/B doubles image storage (not feasible). Recovery slot holds minimal safe firmware to fetch/install image if primary corrupts.

Chunked download & resume

• Server provides manifest with image size, chunk size (e.g., 1024 B), chunk SHA-256 hashes, image version, signature.
• Download loop:
  • Fetch chunks sequentially; write each chunk to a designated update area in flash using append semantics.
  • Maintain a small persistent progress record (last written chunk index + write-state flag) in a dedicated flash page with wear leveling.
  • On reboot, bootloader/app reads progress, resumes from next chunk index.
• Use idempotent writes and a two-phase commit header: HEADER (state: RECEIVING/RECEIVED/VALIDATED) updated atomically.

Cryptographic verification & signing

• Manifest signed with ECDSA P-256 (compact, public-key verification cheap).
• Image integrity: server provides per-chunk SHA-256 and overall image SHA-256. Device computes incremental SHA-256 while writing (streaming) to avoid buffering whole image.
• Verify image SHA-256 then verify signature over manifest + image hash before marking VALIDATED.
• Anti-rollback:
  • Include image version and monotonic counter in signed manifest.
  • Store last-accepted version/monotonic counter in a monotonic storage (secure element, RTC-backed monotonic, or one-time programmable region). If only flash available, store version in multiple slots + use majority/wear-leveling plus monotonic write pattern (append-only counter with invalidation) to make rollbacks hard.
  • Reject installs with version <= stored value.

Signing strategy

• Use PKI: device stores vendor root public key (in read-only bootloader area).
• Sign manifests server-side with ECDSA key; allow key rotation via signed key-cert chain embedded in manifest and validated against root.
• Keep private keys offline in HSM; rotate by publishing new cert signed by root and include new pubkey in manifest signed by root.

Bootloader responsibilities

• Minimal, robust, and immutable:
  • Verify boot image signature/version before jumping.
  • Read update header state: if RECEIVING -> boot recovery or resume download (if bootloader can fetch network); if RECEIVED but not VALIDATED -> compute incremental hash & validate signature.
  • On VALIDATED -> atomically switch active marker to new image and boot.
  • Provide watchdog and inhibit destructive flash operations if power unstable.
  • Implement safe rollback: if new image fails health-check (e.g., fails to report alive within timeout), revert to previous stable image and update monotonic fail counter.

Power-loss & atomicity techniques

• Use append-only writes; each chunk write followed by commit flag for that chunk.
• Use checksum per chunk; on resume, re-read last chunk to verify atomicity.
• Keep small dual headers (current/next) to allow atomic swap via pointer flip.

Testing & validation at scale

• Unit tests: manifest parsing, crypto verification, chunk resume logic.
• Fault-injection tests:
  • Power-cycle at every point in update (before/after chunk write, during validation, during swap).
  • Network interruptions and repeated resumes.
  • Corrupted chunks and signature/manifest tampering.
• Scalability tests:
  • Fleet-rollout simulations with various latencies and packet loss.
  • Canary deployment (small % devices), monitor failure rates, then progressive rollout.
• Security tests:
  • Key compromise scenarios, replay attacks, downgrade attempts.
  • Penetration tests against bootloader and flash wear patterns.
• Long-term reliability:
  • Flash wear testing for progress-record writes (ensure wear-leveling).
  • Stress tests of rollback counter increments and cert rotation.

Trade-offs

• Full A/B gives safest atomicity but not enough flash. Hybrid approach balances safety vs. storage.
• ECDSA chosen for key size and verification cost; alternate: Ed25519 if supported.

This design fits 256 KB flash/32 KB RAM by streaming verification, small recovery slot, append-only state, and minimal bootloader responsibilities while enforcing signature, anti-rollback, and robust resume under power/network faults.

Clarify semantics

• Host = producer of descriptors (writes into shared ring buffer in host RAM).
• Device = consumer (reads ring via DMA), head index is MMIO-owned by device, tail index is in host RAM.
• Goal: host must make descriptor fully visible before publishing tail; device must see tail update before reading descriptor.

Rules used

• On ARM use store-release / smp_wmb() on producer before publishing tail.
• Device uses load-acquire / smp_rmb() (or ensure MMIO read is strongly ordered) after reading tail before accessing descriptors.

Producer (host) pseudocode (C-like)

// produce descriptor at slot 't'
buffer[t] = desc;            // plain store(s) to descriptor fields
smp_wmb();                   // ensure stores to buffer complete before tail publish
tail = new_tail;             // publish tail (plain store or with release)

Consumer (device) pseudocode

// device reads tail (from host RAM via DMA/MMU)
u32 seen_tail = read_tail(); // must be an ordered load (MMIO read or load-acquire)
smp_rmb();                   // ensure tail load completes before reading descriptor data
desc = buffer[i];            // now safe to read descriptor fields

Why

• smp_wmb() guarantees all descriptor stores reach memory and are globally visible before the tail store — prevents device seeing tail pointing to a descriptor still being written.
• smp_rmb() (or load-acquire) on device guarantees that after seeing the updated tail, subsequent reads of descriptor memory observe the fully-written descriptor.
• If tail publish uses release-store and device uses acquire-load, the same happens via hardware acquire/release semantics.

Notes & edge cases

• If device reads tail via MMIO that is strongly ordered, an explicit rmb may be unnecessary; verify platform DMA coherency (cache maintenance) so device doesn't see stale descriptors.