Introducing SAM E51 CRC Peripheral

Last modified by Microchip on 2026/07/10 12:23

Introduction

Modern embedded systems must move and store data reliably in the presence of electrical noise, high‑speed buses and complex software. As data rates increase and power budgets shrink, it becomes impractical for the Central Processing Unit (CPU) to continuously verify data integrity in software. To address this, the SAM E51 family of microcontrollers from Microchip Technology integrates a Cyclic Redundancy Check (CRC) engine directly into the Direct Memory Access Controller (DMAC).

Data Integrity and the Role of CRC

Data integrity refers to the assurance that data has not been accidentally altered during storage or transmission. In embedded systems, data corruption can occur due to electromagnetic interference, bus contention, clock domain crossings, or memory faults. Even a single flipped bit can render a firmware image invalid or corrupt a communication packet.

A CRC is a mathematical technique that detects accidental data corruption by treating data as a binary polynomial and dividing it by a fixed generator polynomial. The remainder of this division is the CRC value. When data is later checked, the same calculation is performed and the result is compared against the expected value.

CRC is preferred over simple checksums because it detects a much wider class of errors, including burst errors and bit reordering. In embedded systems, CRC is commonly used for communication protocols, memory validation at boot, firmware integrity checks and safety‑critical data paths.

CRC in the SAM E51 Architecture

The SAM E51 is a high‑performance Arm^® Cortex^®‑M4F‑based microcontroller designed for real‑time connectivity and control applications. Within its system architecture, the DMAC acts as a bus master capable of moving data between memory and peripherals without CPU intervention.

Rather than implementing CRC as a standalone peripheral, Microchip integrates the CRC generation logic directly inside the DMAC. This design allows CRC computation to occur naturally as data flows through a DMA channel. The CPU, DMAC and CRC engine operate in parallel: the CPU configures the transfer, the DMAC moves the data and the CRC engine evaluates each data beat as it passes through.

This tight integration eliminates redundant memory reads and enables CRC computation on data streams that never need to be stored in memory.

Purpose and Benefits of DMAC‑Based CRC

The primary purpose of DMAC‑based CRC is to offload data integrity checking from the CPU while maintaining deterministic behavior. Instead of looping through buffers in software, the CPU configures the DMAC once and is free to perform other tasks or enter a low‑power state.

The benefits are significant. CPU utilization is reduced to near zero during CRC calculation. Timing becomes fully deterministic because CRC execution is tied directly to DMA transfers. Power consumption drops because fewer instructions are executed. CRC calculation scales efficiently to large data blocks, and overall system throughput improves by overlapping data movement and verification.

Compared to software‑based CRC, DMAC CRC is faster, more power‑efficient and less error‑prone, particularly in systems with continuous data streams.

High‑Level Operation of DMAC CRC

In SAM E51 devices, CRC generation is an optional feature of a DMA transfer. When enabled, the CRC engine processes each beat of data read by the DMA channel. A beat is a single transfer unit, typically 8, 16, or 32 bits.

Conceptually, the flow is simple. A DMA channel reads data from a source address. As each beat is read, the CRC engine updates its internal checksum. The data may then be written to a destination or discarded entirely. After the transfer completes, the final CRC value is available in a dedicated CRC Checksum register (CRCCHKSUM).

The DMAC supports memory‑to‑null transfers, where data is read solely for CRC calculation without being stored anywhere. Supported data sources include Static Random‑Access Memory (SRAM), Flash memory, and peripheral data streams such as Serial Peripheral Interface (SPI) or Universal Asynchronous Receiver‑Transmitter (UART) interface.

CRC Fundamentals on SAME51

CRC operation relies on a few core concepts. The polynomial defines the error‑detection properties. The seed is the initial CRC value loaded before computation begins. The bit width determines the size of the CRC result.

On SAM E51 devices, the primary supported standard is CRC‑32, which produces a 32‑bit checksum and is widely used in networking and storage systems. Data ordering matters; CRC is calculated on the exact sequence of bits presented to the engine, making beat size and byte order important considerations. The CRC engine processes data as it appears on the DMA read path, so software must ensure consistency with external CRC references.

DMAC Features Relevant to CRC

To understand DMAC CRC, it is necessary to understand basic DMAC structure. Each DMA transfer uses a channel, which is configured using a transfer descriptor stored in SRAM. A descriptor defines the source, destination, transfer count and control options for a block transfer.

A block consists of multiple beats, which may be grouped into bursts depending on arbitration. The CRC engine operates at the beat level, accumulating CRC values continuously across beats and blocks. CRC operation is coordinated with the DMAC arbiter, ensuring that CRC computation remains synchronized even when channels are paused or preempted.

See the "Understanding SAM E51 Direct Memory Access Controller (DMAC) Units of Transfer" page to learn more about units of transfer.

Configuring CRC in the DMAC

CRC is enabled per DMA channel using fields in the Block Transfer Control (BTCTRL) portion of the descriptor and the global CRC control registers. The configuration selects CRC‑32 mode and defines the CRC source as DMA read data.

Before starting a CRC calculation, software initializes the CRC seed in CRCCHKSUM. CRC generation begins automatically when the DMA channel starts transferring data. Clearing or restarting CRC requires disabling the CRC source and reloading the seed.

Notably, SAM E51 devices do not use a separate CRC enable bit. CRC is enabled or disabled by configuring the CRC source field appropriately, as documented in the product data sheet.

CRC Data Flow and Accumulation

CRC values accumulate continuously across beats within a block and can optionally continue across multiple blocks when linked descriptors are used. If a channel is suspended, CRC accumulation pauses. If the channel is disabled, CRC computation stops.

CRC results become valid only after the final beat of the transfer has been processed. Software must ensure that the DMA transfer is complete before reading the CRC result.

Reading and Using the CRC Result

The final CRC value is stored in the DMAC’s CRCCHKSUM register. Software retrieves this value after confirming that the DMA channel has completed its transfer, typically using a channel interrupt or status flag.

Proper synchronization is critical. Reading the CRC too early yields an incomplete result. Once retrieved, the CRC can be compared against a known‑good value to validate memory contents or received data.

CRC With Linked DMA Descriptors

Linked descriptors allow CRC computation across large or non‑contiguous memory regions without CPU involvement. CRC can either continue seamlessly across descriptor boundaries or be restarted by reinitializing the seed. This capability supports circular buffers, streaming communication protocolsexplicitly resets the CRC state and scatter‑gather memory layouts.

CRC and DMA Triggers

CRC works with both software triggers and peripheral triggers. In peripheral‑driven transfers, such as SPI or UART reception, CRC is calculated in real time as data arrives. This enables immediate validation of incoming data without buffering or CPU polling.

Error Handling and Edge Cases

If a DMA transfer is aborted or a descriptor error occurs, CRC results may be partial and must be discarded. Bus faults halt CRC computation. Robust software explicitly resets CRC state before restarting transfers to avoid contamination from previous calculations.

Performance and Power Considerations

CRC throughput is directly tied to DMA throughput. Larger beat sizes and efficient burst configurations improve performance. Arbitration and Quality of Service (QoS) settings influence latency but not CRC correctness. Compared to software CRC, DMAC CRC offers substantial power savings and predictable real‑time behavior.

Practical Use Cases

Common patterns include boot‑time memory integrity checks, firmware image validation, real‑time communication data verification and safety‑critical monitoring. DMAC CRC is especially valuable where data must be validated continuously with minimal latency.

Microchip Technology Tools and Solutions

Microchip Technology provides extensive support for DMAC CRC on SAME51 devices. MPLAB^® Harmony v3 includes ready‑to‑use DMAC CRC‑32 Generation examples. Atmel START simplifies DMA and CRC configuration through a graphical interface. Debugging and validation are supported using MPLAB X IDE and the MPLAB Data Visualizer.

Common Pitfalls and Best Practices

Errors often stem from incorrect descriptor configuration, failing to initialize the CRC seed, mismatched endianness, or forgetting to enable CRC per block. Best practice is to validate DMAC CRC results against a trusted software CRC during development and to explicitly reset CRC state between independent calculations.

Summary

The DMAC‑based CRC engine in the SAM E51 microcontroller family provides a powerful, efficient and deterministic method for ensuring data integrity. By computing CRC values as data moves through the system, CPU overhead is eliminated, while performance and power efficiency improve. Understanding how CRC integrates with DMA channels, descriptors and triggers enables engineers to build robust, high‑reliability systems using the full capabilities of SAM E51 devices.