Microcontrollers, SoCs, and Development Boards Questions

Brief overview
Caches (I-cache and D-cache) hold copies of main memory to speed CPU access. DMA and memory-mapped peripherals bypass the CPU cache and access main memory, so coherence issues arise when buffers are cached. Proper cache maintenance and memory attributes are required to avoid stale or lost data.

Memory attribute configuration

• Device memory: non-cacheable, strongly ordered or device type in MMU. Used for MMIO; CPU must not cache these addresses.
• Normal memory: cacheable (write-back or write-through) and possibly bufferable. Use normal memory for bulk data buffers but enforce coherence when DMA is involved.
• For DMA buffers, prefer normal memory with cacheable disabled for simplicity or keep cacheable and perform maintenance.

Cache maintenance ops

• Invalidate (D-cache invalidate): discard cache lines so future CPU reads fetch fresh data from RAM. Use before CPU reads data that DMA wrote.
• Clean (D-cache clean / write-back): write dirty cache lines to RAM without invalidating. Use before DMA reads memory that CPU wrote.
• Clean-Invalidate: write back then invalidate; used when DMA will both read and CPU will later read modified data.
• I-cache invalidate: required if code in memory is updated (e.g., DMA writes executable code); invalidate I-cache lines or perform combined barrier.

Always use processor memory barriers:

• Data Memory Barrier (DMB) to order memory accesses.
• Data Synchronization Barrier (DSB) to ensure completion of cache maintenance before continuing.
• Instruction Synchronization Barrier (ISB) after I-cache invalidation to synchronize fetched instructions.

Safe DMA sequences

1. CPU -> DMA (device reads memory)

   • If buffer is in D-cache and may be dirty:
     • D-cache clean the buffer region (write-back).
     • DSB to ensure write-back completes.
   • Start DMA transfer.
   • No invalidate needed on CPU side before DMA finishes.

2. DMA -> CPU (device writes memory)

   • Ensure buffer region is either non-cacheable or:
     • Before DMA starts, D-cache invalidate the buffer region (discard stale lines).
     • DSB to ensure invalidate completes.
   • Start DMA.
   • After DMA completes, DSB (ensure DMA visibility), then CPU may read—no further invalidate needed if invalidated before DMA; if not, perform invalidate then DSB.
   • If DMA wrote code/data that CPU will execute: after invalidation, perform ISB to sync I-cache.

3. Bidirectional (shared) buffer

   • Before DMA reads: clean.
   • After DMA writes: invalidate (or clean-invalidate across overlap).
   • Use clean-invalidate if buffer may contain dirty lines and you want both write-back and discard.

Practical tips

• Align maintenance to cache line boundaries to avoid leaving partial dirty lines.
• Use DMA-capable, non-cache-coherent APIs (Linux: dma_map_single/dma_unmap) that do these operations for you.
• Consider using non-cacheable pools or hardware that supports cache-coherent DMA to simplify drivers.

This sequence and use of barriers prevents stale reads, lost writes, and ensures correctness when CPU cache and DMA/peripherals share memory.

Brief answer (why it matters)
Memory alignment affects how the CPU, DMA controller and peripheral buses access RAM. Misaligned accesses can cause bus faults on some MCUs (especially when peripherals or DMA require word/double-word alignment) or force the hardware to do multiple narrower accesses — causing performance penalties.

Common issues & examples

• DMA configured for 32-bit transfers to a buffer at 0x20000002 -> bus fault or corrupted data on Cortex-M with strict alignment.
• Packed struct used for a peripheral descriptor: attribute((packed)) removes padding but yields fields not 4‑byte aligned; DMA reading it may be slower or cause errors.
• Cached SRAM: DMA writes bypass cache causing stale data if cache clean/invalidate not done.

How to ensure DMA-safe buffers and structs

• Force alignment in C:

/* GCC/clang: 32-bit alignment for DMA buffer */
uint32_t dma_buf[256] __attribute__((aligned(4)));
/* For a descriptor */
struct desc { uint32_t ctrl; uint8_t flags; } __attribute__((aligned(4)));

• Use padding instead of packed for peripheral structures:

struct foo { uint32_t a; uint8_t b; uint8_t pad[3]; }; /* ensures 4-byte stride */

• Linker placement: put DMA buffers in non-cached SRAM section and align in linker script:

/dma_buffer : ALIGN(4) { KEEP(*(.dma_buf)) } > SRAM

• For toolchain directives/assembly: use .align 2 (for 4-byte) in assembly.

Runtime measures

• Check peripheral/DMA docs for required alignment and transfer size.
• If buffer may be misaligned, use CPU memcpy to an aligned bounce buffer or configure DMA for byte/halfword transfers (slower).
• On cacheable memory, perform data cache clean/invalidate around DMA.

Summary (practical rules)

• Prefer natural alignment for fields accessed by DMA (4/8 bytes as required).
• Avoid attribute((packed)) for DMA descriptors; add explicit padding.
• Place and align buffers via attributes and linker script; handle cache maintenance.

Clarify goal & constraints
Port low-level AVR drivers to Cortex‑M (32‑bit, Thumb). Focus: correctness, performance, and ABI/IRQ compatibility. I assume C/C++ with CMSIS available.

Major hardware/software differences

• Register width & alignment

  • AVR: 8‑bit registers; Cortex‑M: 32‑bit registers and bus. Accessing 8/16/32‑bit registers matters: use correct-sized volatile accesses (uint32_t for 32‑bit regs).
  • Cortex‑M often faults on unaligned 32‑bit accesses (some cores allow but slower). Ensure struct packing and pointers are 32‑bit aligned.

• Endianness

  • AVR is effectively byte-addressed little 8‑bit; Cortex‑M is little‑endian. Byte order differences mostly affect multi‑byte peripheral FIFOs, DMA descriptors, and wire protocols—verify byte-swapping when moving data buffers or peripheral descriptors.

• ISR entry/exit conventions

  • AVR uses simple push/pop in ISR attributes. Cortex‑M uses hardware stacking/unstacking of R0–R3, R12, LR, PC, xPSR; the handler signature should match CMSIS (void IRQnHandler(void)). Don’t use custom assembly prologues—use CMSIS prototypes and attribute((interrupt)) is not portable; rely on compiler + NVIC.
  • FPU: on FPU cores, lazy stacking changes stack frame size; mark functions that use FP appropriately or enable full stacking.

• Interrupt priorities

  • AVR priority is simple. Cortex‑M has configurable priority fields (NVIC) and preemption/subpriority bits. Use BASEPRI/PRIMASK for critical sections and understand that lower numeric priority = higher urgency. Map AVR priority model to NVIC properly and set priority grouping.

• Calling conventions / ABI

  • Cortex‑M follows ARM AAPCS (R0–R3 args, R0 return, R4–R11 callee-saved). Stack must be 8‑byte aligned at exception entry. Port functions expecting caller‑saved/callee‑saved registers need review. Inline assembly must preserve callee-saved regs.

• Memory model

  • 32‑bit pointers, larger address space. Watch pointer/integer casting, pointer truncation, and data size (size_t is 32/64). Update linker scripts for flash/ram regions and vector table placement. Peripheral MMIO addresses are 32‑bit words; use CMSIS register definitions.

Common pitfalls and mitigations

• Assuming char==8-bit still true, but assuming registers/IO are 8-bit is wrong—use proper widths.
• Bitfields: compiler ordering differs; avoid bitfields for hardware registers—use shifts & masks or CMSIS SFR definitions.
• Atomicity: 8‑bit atomic ops on AVR may not be atomic on 32‑bit bus for multi‑byte variables; use LDREX/STREX or disable interrupts.
• Struct packing and alignment causing hard faults—use static_asserts and attribute((packed, aligned(4))) only when needed.
• Stack usage in ISRs: larger automatic arrays can overflow—keep ISR stack small; increase main stack (MSP) in linker.
• Vector table and weak IRQ handlers: ensure correct names/signatures per vendor/CMSIS.
• Endianness in DMA/peripheral descriptors: ensure hardware expects little‑endian layout; byte-swap if necessary.
• Compiler flags: use -mthumb -mcpu=cortex-mX -mfloat-abi appropriately; enable CPU-specific optimizations carefully.
• Testing: run on hardware with JTAG/SWD, exercise interrupts, low-power modes, and DMA.

Practical steps

• Import CMSIS headers, replace AVR register macros with CMSIS SFRs.
• Audit all volatile accesses, remove bitfields for registers, add masks/shifts.
• Update ISR definitions to CMSIS handlers, set NVIC priorities, and test preemption.
• Update linker script, heap/stack sizes.
• Add unit/hardware tests for endianness, alignment faults, and atomic operations.

Result: predictable, maintainable drivers that respect Cortex‑M ABI, memory model, and interrupt semantics.

Approach (one-liner)
Use the DMA in circular (ring) mode to move ADC data registers into a RAM buffer with source fixed and destination incrementing; use half/full-transfer interrupts to process data without halting the stream and detect overruns.

Key DMA config parameters

• Source address: ADC data register (fixed, no increment).
• Destination address: buffer base in RAM (increment enabled).
• Data width: match ADC sample size (e.g., 16-bit) so transfers are atomic and aligned.
• Transfer length: buffer length in samples (N).
• Circular mode: enabled so DMA wraps destination automatically.
• Priority & FIFO: set according to bus contention; enable peripheral-to-memory direction.

Handling wrap-around & interrupts

• Enable Half-Transfer (HT) and Transfer-Complete (TC) interrupts. HT fires when first N/2 samples written — safe to process first half while DMA writes second half. TC fires at end of buffer — process second half. This avoids contending with DMA writes.

Overrun detection & recovery

• Detect by tracking processing latency vs sample rate: if HT/TC occurs before you finish processing previous half, set an overrun flag. Also read ADC/DMA error/status bits (some MCUs expose FIFO overrun or DMA transfer error).
• Recovery steps:
  • Disable relevant interrupts, optionally pause ADC trigger or stop DMA.
  • Clear hardware error flags.
  • Reset buffer pointers or resync by reading current DMA destination index (many DMA controllers expose NDTR or current target address) and align processing start.
  • Re-enable DMA and interrupts. If data continuity is critical, log loss and notify higher layer.

Notes & best practices

• Use double-buffering abstraction if processing time variable.
• Keep ISR short: set flags or copy small headers, defer heavy work to a task/worker.
• Ensure memory region is DMA-capable and cache-coherent; if using cache, use cache maintenance (invalidate/writeback) when CPU reads DMA-updated RAM.

Definition & why it matters

• Endianness = byte order used to represent multi-byte values in memory: little-endian stores least-significant byte first; big-endian stores most-significant byte first.
• Practical effect: misinterpreting order gives wrong numeric values, wrong protocol fields, corrupted DMA transfers.

Effects

• Reading multi-byte hardware registers
  • CPU vs peripheral endianness mismatch means reading a 32-bit register as 0xAABBCCDD could yield 0xDDCCBBAA.
  • Use volatile reads and explicit byte-swapping if peripheral and CPU differ.
• Packing data for network (big-endian by convention)
  • Convert to network byte order (htonl/htons) before transmit; parse with ntohl/ntohs on receive.
• DMA between peripheral and memory
  • DMA transfers copy raw bytes. If peripheral expects different ordering, either configure DMA hardware byte-swap feature or perform swap in software/driver.
  • Watch caches and alignment: use cache maintenance and aligned buffers to avoid stale/incoherent data.

Portable coding patterns (embedded C)

• Detect CPU endianness at compile-time and use helpers:

#include <stdint.h>

static inline uint32_t bswap32(uint32_t x) { return __builtin_bswap32(x); }

#if defined(TARGET_BIG_ENDIAN)
  #define cpu_to_dev32(x) (x)        /* device big-endian */
  #define dev_to_cpu32(x) (x)
#else
  #define cpu_to_dev32(x) bswap32(x) /* device big-endian, CPU little */
  #define dev_to_cpu32(x) bswap32(x)
#endif

/* safe register write */
static inline void write_reg32(volatile void *addr, uint32_t val)
{
    uint32_t v = cpu_to_dev32(val);
    /* use memcpy to avoid strict-aliasing/unaligned issues */
    memcpy((void*)addr, &v, sizeof(v));
}

• Use htonl/ntohl when implementing protocols.
• For DMA: allocate aligned, non-cached buffers or manage cache; if DMA supports endian config, set it; otherwise swap in ISR or worker.

Summary
Always document peripheral endianness, encapsulate conversions in small helpers, prefer hardware byte-swap when available, and ensure cache/alignment correctness for DMA.