Hardware/Software Co-Design and Resource Constraints Questions

Memory budget (fits 128 KB)

• TLS stack: 12 KB
• Sensor sampling task: 6 KB (down from 4 KB estimate to include margin)
• Data processing task: 20 KB (was 16 KB, add margin)
• Logger task: 8 KB
• Runtime buffers (I/O, DMA): 24 KB
• Heap: 10 KB
• RTOS + kernel, ISRs, globals, BSS, .data, C library: 30 KB

Total = 12 + 6 + 20 + 8 + 24 + 10 + 30 = 110 KB (18 KB headroom for growth/stack slack)

How I chose stack sizes

• Start from worst-case static estimates, then add safety margin (20–25%) for interrupts, API call depth, and library stacks (TLS uses crypto libs so kept at 12 KB).
• Give more margin to data processing (deep recursion or large local buffers).
• Keep sensor sampling minimal but increased slightly to avoid overflows during logging or fault handling.

Tools & methods to measure real stack usage

• Linker map to see static sizes for .bss/.data/heap.
• Compile-time stack canaries or guard words and periodic stack watermarking (fill stacks with 0xAA and read high-water mark).
• Use RTOS-built functions (FreeRTOS uxTaskGetStackHighWaterMark).
• Hardware features: MPU/stack guard, CPU fault handlers to capture stack overflows.
• Runtime tracing with semihosting or RTT to log watermarks during stress tests.

Concrete optimizations if RAM is tight

• Reduce stacks: profile and shrink to observed high-water + 10–20% margin.
• Move large local buffers to static/global or DMA buffers placed in tightly controlled memory region.
• Share stacks for low-concurrency tasks (stack pooling) or use a single worker thread for rarely concurrent jobs.
• Offload TLS session state or heavy buffers to external flash or reduce cipher suite footprint (use smaller crypto library).
• Use compiler options: -Os, link-time optimization, remove RTTI/exception support in C++.
• Convert fixed-size buffers to dynamically allocated ones with strict lifetime and pooling.
• Reduce heap by streaming data instead of buffering.

I would iterate: measure watermarks under worst-case load, adjust budgets, then re-run tests and enable stack overflow detection in production.

Brief definition & when to prefer
Fixed-point represents numbers as integers scaled by 2^F (F = fractional bits). On MCUs without an FPU it's preferred because it's faster, deterministic, uses less code and power, and gives tight control of precision and overflow—important in real-time control and DSP.

Q-format (example Q15.16)

• Q15.16 means 15 integer bits (including sign) and 16 fractional bits. Value stored = integer N; real = N / 2^16.

real = N / 65536.0

Multiply & divide (scaling)

• Multiplication: use a wider accumulator, then shift right by F:

int64_t tmp = (int64_t)a * (int64_t)b;
int32_t result = (int32_t)(tmp >> 16); // for Q15.16

• Division: shift left then divide to preserve fraction:

int64_t tmp = ((int64_t)a << 16) / b;
int32_t result = (int32_t)tmp;

Saturation & overflow detection

• Detect overflow by checking tmp against 64-bit limits, then clamp to INT32_MAX/INT32_MIN.
• Alternatively use builtin intrinsics (CMSIS) or compiler intrinsics for saturating arithmetic.

Precision & pitfalls

• Fraction bits determine resolution (2^-16 ≈ 1.5e-5). Watch dynamic range: fewer integer bits limit max magnitude.
• Round by adding (1 << (F-1)) before shift.
• Use wider accumulator to avoid intermediate overflow.

Typical use cases

• PID loops, motor control, audio DSP (filters, FFTs), sensor fusion on microcontrollers without FPU.

This approach yields deterministic, efficient arithmetic suitable for resource-constrained embedded systems.

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.

Situation & goal
Systematically determine why the device resets when BLE transmits at max power and produce actionable fixes for HW and FW teams.

Stepwise debugging plan

1. Reproduce reliably

• Run continuous TX at max power and log timestamps of resets (UART or persistent counter in flash).

2. Measure power rails & ground

• Use oscilloscope across VCC and ground at device supply entry and at PMIC output. Look for dips, slow recovery, ringing, and overshoot.
• Measure other rails (RF PA bias, digital core, IO) simultaneously if available.

3. Current and scope measurements

• Use a high-bandwidth current probe or series shunt + differential probe on supply to capture fast current pulses during TX bursts.
• Trigger scope on TX start (GPIO or BLE TX indicator) and capture >10× before/after window to see baseline.
• Collect long-duration trace with logging to spot thermal or cumulative effects.

4. Additional observables

• Measure ground bounce: probe ground near MCU and near RF PA simultaneously (use differential probes).
• Check PMIC telemetry (if present): VIN, VOUT, current limit events, watchdogs.
• Monitor RF envelope with power detector to correlate peak power to reset.

Likely root causes

• Hardware: supply droop (brownout) due to inadequate decoupling, insufficient supply trace width or vias, PMIC transient limit, thermal shutdown of PA, ground bounce causing MCU brownout.
• Firmware: improper regulator sequencing, enabling full-power TX without boosting regulator or disabling DVFS, blocking low-power modes that affect brownout thresholds, or watchdog misconfiguration.

Short-term fixes

• Reduce TX power or duty cycle via firmware; add retries and backoff.
• Increase MCU brownout threshold or add software brownout handler to log cause.
• Add local decoupling (ceramic caps) near PA and MCU; add a bulk electrolytic or tantalum on board near PMIC output.

Long-term fixes for HW team

• Re-evaluate power distribution: increase copper, add vias, lower ESR bulk cap at supply, add dedicated PA supply or LDO with adequate transient response.
• Tune PMIC current limit or add boost regulator/charge pump for TX peaks.
• Improve ground plane layout and star grounding; add ferrite bead/isolation between analog RF and digital cores.

Long-term fixes for FW team

• Implement TX power ramping, envelope shaping, or staggered TX scheduling.
• Query PMIC telemetry and delay TX until rails are stable; add logging around resets.
• Use adaptive power control linked to thermal and supply conditions.

Success criteria

• No resets during stress TX test for defined duration; measurable transient amplitude within PMIC headroom; clear correlation removed between TX events and resets.

Approach (brief)

• Poll MMIO register until (reg & ready_mask) != 0 or timeout expires.
• Use short sleeps to avoid busy-spin; yield first then progressively sleep.
• Use volatile read with explicit memory barrier to ensure ordering.
• Tolerate spurious reads by requiring the ready bit to be observed twice in a row.

Sample implementation

#include <stdint.h>
#include <time.h>
#include <unistd.h>
#include <sched.h>

static inline void mmio_rmb(void) { __asm__ volatile ("" ::: "memory"); }

int wait_ready(uintptr_t base, uint32_t offset, uint32_t ready_mask, uint32_t timeout_ms) {
    const long start_ms = (long)(clock_gettime);
    struct timespec ts;
    clock_gettime(CLOCK_MONOTONIC, &ts);
    long start = ts.tv_sec * 1000 + ts.tv_nsec / 1000000;

    int consecutive = 0;
    uint32_t val;
    while (1) {
        volatile uint32_t *reg = (volatile uint32_t *)(base + offset);
        mmio_rmb();
        val = *reg;
        mmio_rmb(); /* barrier after read if required by platform */

        if (val & ready_mask) {
            if (++consecutive >= 2) return 0; /* stable ready */
        } else {
            consecutive = 0;
        }

        clock_gettime(CLOCK_MONOTONIC, &ts);
        long now = ts.tv_sec * 1000 + ts.tv_nsec / 1000000;
        if ((uint32_t)(now - start) >= timeout_ms) return -1; /* timeout */

        /* avoid busy spin: yield then short sleep */
        sched_yield();
        if ((uint32_t)(now - start) < 10) usleep(100); else usleep(1000);
    }
}

Notes

• Uses CLOCK_MONOTONIC for timeout. Adjust barriers (mmio_rmb) to platform-specific I/O barriers if needed.
• Returns 0 on success, -1 on timeout. Adjust error codes per project conventions.