Transfer Widths, Alignment, and Address Increment

A channel moves one item per transfer, of the size set in its control word: a byte, a half-word (16 bits) or a word (32 bits). The pico-sdk names these DMA_SIZE_8, DMA_SIZE_16 and DMA_SIZE_32; the STM32 HAL has separate peripheral and memory widths (DMA_PDATAALIGN_…, DMA_MDATAALIGN_…); Zephyr gives source and destination widths in bytes. Two things decide the size:

• the peripheral register: a data register is designed to be accessed with a particular width, and each access typically pops or pushes one FIFO entry;
• the element type of the buffer: 16-bit samples need 16-bit transfers, or the peripheral must be told to produce a narrower format. pico-examples’ ADC capture shifts each 12-bit result down to 8 bits so that it can use byte transfers into a byte buffer.

The RP2040’s TRANS_COUNT counts transfers, and the STM32 HAL’s data length counts data items, not bytes (1 to 65 535; its UART driver passes a count of uint8_t or uint16_t elements straight through). Zephyr’s block_size, by contrast, is in bytes. For a transfer count $N$ and transfer size $s$:

sizeof gives bytes. For an array of elements the right count is usually the element count, sizeof(buf) / sizeof(buf[0]), with the transfer size equal to the element size.

↑ This step uses the figure at the top of the page.

After each transfer an address either stays put or advances by the transfer size. A peripheral data register must stay put; a buffer must advance. Get it wrong and a memory-to-peripheral transfer sends the first byte over and over (read address fixed) or writes into the registers that follow the data register (write address incrementing); a peripheral-to-memory transfer with a fixed write address puts every item in the same location, so only the last survives. The RP2040’s default configuration (32-bit, read increment on, write increment off, unpaced) has the address pattern of memory to peripheral; for receiving you must change both increments. Some controllers can also decrement, useful for reversing a buffer.

Transfers of a half-word or a word should use addresses that are multiples of 2 or 4. What a controller does with a misaligned address varies (a bus error, the low bits ignored, the access split in pieces), so portable code never relies on it. C already aligns an array to its element type, so uint16_t buf[8] is safe for 16-bit transfers. The dangers come from addresses you compute:

• a pointer into the middle of a byte array, such as &packet[3], used for 32-bit transfers;
• a member of a packed structure (unit 2, lesson 4);
• a buffer placed by hand in a linker section without ALIGN (unit 4, lesson 4).

When in doubt, declare the buffer with __attribute__((aligned(4))), or stricter where lesson 4 (ring buffers) or lesson 6 (cache lines) needs it.

Data from a big-endian device (many sensors and network protocols send the most significant byte first; unit 2, lesson 4) arrives in the wrong byte order for a little-endian CPU. Some DMA controllers can fix it on the way: the RP2040’s BSWAP option swaps the two bytes of each half-word, or reverses the four bytes of each word, during the transfer.

uint16_t samples[64] occupies 128 bytes. With 16-bit transfers and read increment off (the peripheral’s data register), write increment on:

• correct: count = 64 elements, 64 × 2 = 128 bytes, exactly the array;
• with sizeof(samples) = 128 as the count: 128 × 2 = 256 bytes, 128 bytes past the end, over whatever the linker placed next (here, the status variable);
• with 8-bit transfers and count 64: only 64 bytes, half the array, and each 8-bit read of the peripheral’s 16-bit data register returns at most part of a sample.

The fix is dma_channel_configure(ch, &c, samples, &periph_data, count_of(samples), true) with DMA_SIZE_16, where count_of is the pico-sdk’s element-count macro. A map file (unit 4, lesson 5) shows what lies after the array, which explains the symptom.