DMA glitch?

[Ludo-lab]

Hello everyone,

I’m seeing odd behavior on a Raspberry Pi Pico H (RP2040) running MicroPython 1.25.0.

I am trying to generate a sine wave with variable frequency using PWM and DMA. What the code do:

• PWM running on a GPIO pin.
• A buffer holds a sine table scaled to the TOP maximum count.
• A DMA channel updates the PWM TOP register on each PWM wrap DREQ.

For a long time I couldn’t get a clean sine after the RC filter; then, without after randomly adding some lines, it suddenly looked fine on the scope (see picture below for the setup and the sine).

I was quite happy, I can vary the sine period from 10–1000 Hz just fine. However, if I comment out a single line—or even change which library I import—the filtered output changes dramatically. Sometimes the sine is distorted or disappears. The exact waveform seems to depends on which line/module is present, and also the MicroPython version, for example the picture below shows how it look on MicroPython 1.26.00

I’m trying to understand what could cause this intermittent behavior. Could you recommend some approaches?

Here below is reported the script and here can be found the mcp4728.py and utils.py
NB: I tried to import the library in mcp4728 without importing mcp4728 but I have the same behaviour.
PDM.zip

import math, rp2
from machine import Pin, PWM, I2C
from uctypes import addressof
from array import array
import machine
import utils
import mcp4728
import time


# i2c = I2C(0,scl=Pin(9),sda=Pin(8),freq=400_000) # Define I2C pins

# time.sleep(1)

# # --- User configuration for 1kHz sine in 100kHz PWM ---
LED_PIN      = 12      # GPIO pin driving your LED (via MOSFET, etc.)

SINE_FREQ = 200         # Desired sine wave frequency (Hz)
SINE_SAMPLES = 2**8       # Number of samples per sine period (power of two recommended)
PWM_CARRIER = SINE_FREQ *  SINE_SAMPLES  # PWM carrier frequency (Hz), much higher than SINE_FREQ

slice_idx = LED_PIN // 2
CC_OFFSET = 0x0C
DIV_OFFSET = 0x04
TOP_OFFSET = 0x10 
CC_ADDR  = 0x40050000 + slice_idx * 0x14 + CC_OFFSET
DIV_ADDR = 0x40050000 + slice_idx * 0x14 + DIV_OFFSET
TOP_ADDR = 0x40050000 + slice_idx * 0x14 + TOP_OFFSET

# Configure the hardware PWM slice
pwm = PWM(Pin(LED_PIN))
pwm.freq(PWM_CARRIER)       # set carrier frequency
pwm.duty_u16(2**16 //2)      # initiliaze in 50% duty-cycle

top_value =machine.mem32[TOP_ADDR]

# Build a 16‑bit sine lookup table for 1kHz in 100kHz envelope
num_samples = SINE_SAMPLES#int(SAMPLE_RATE // SINE_FREQ)  # 100 samples for 1kHz@100kHz
sine_buf = array('h', (0 for _ in range(num_samples)))
for i in range(num_samples):
    # sin() → [–1..1] → [0..1] → [0..65535]
#     v = (math.sin(2 * math.pi * i / num_samples) + 1) * 0.5  # 0..1
    v = (math.sin(2 * math.pi * i / num_samples + math.pi/2) + 1) * 0.5
    sine_buf[i] = int(round(v * (top_value-1))) # normalize to the TOP_ADDR value

# Setup the DMA, pick the right DREQ for “PWM slice wrap”
DREQ_PWM_WRAP6 = 30 # DREQ_PWM_WRAP6

# --- Single-channel circular DMA for jitter-free PWM sine output ---
buf_bytes = num_samples * 2  # 2 bytes per 'H' sample
ring_size = int(math.ceil(math.log2(buf_bytes)))

# Use the address for channel A (no offset), and ensure DMA is triggered
dma = rp2.DMA()
ctrl = dma.pack_ctrl(
    size=1,              # 1 = 16-bit transfers
    inc_write=False,     # always write to the same CC register
    inc_read=True,       # advance through the sine_buf
    ring_size=ring_size, # wrap at 2^ring_size bytes
    ring_sel=False,      # wrap the read address (sine_buf)
    treq_sel=DREQ_PWM_WRAP6
)

dma.config(
    read=sine_buf,
    write=CC_ADDR,
    count=0xFFFFFFFF,  # continuous transfer
    ctrl=ctrl,
    trigger=False
)
dma.active(1)

[GitHubsSilverBullet]

If you use a DMA ring buffer, you need to make sure that it starts at a correct address.
In your case, a 256 HALFWORD (512 byte) buffer needs to start at a 512 byte boundary, ie. the lower 9 address bits must be ›0‹
The easiest way to accomplish this is to allocate twice the required buffersize and do some address juggling so that the correct start address AND length are within the allocated buffer.

[Ludo-lab]

I now think that it is indeed not a bug.
I notice is that when the script works, my sine_buf is initiated at 0x20008a00 (which is a divider of 512).
Thanks for the example regarding the addresses and the masking.
I am trying to initiate the sine_buf using uctypes.bytearray_at(0x20008a00, SIZE)

[peterhinch]

Apologies - I thought the issue was word-alignment. It is evidently RING_SIZE alignment. Nevertheless the essence of my approach should work: allocate a bytearray of size 2*RING_SIZE. Find its start address using uctypes.addressof(). Determine the first address in the buffer which has all the ringsize bits 0. Use uctypes.bytearray_at() to create the actual ring buffer within the allocated RAM.

I am trying to initiate the sine_buf using uctypes.bytearray_at(0x20008a00, SIZE)

You need to ensure that the memory at that address is allocated, otherwise MicroPython might use it for something else. Hence my suggestion above.

PS. That's why I'd like to see a bytearray(numitems, adr=address)

See https://docs.micropython.org/en/latest/library/uctypes.html#uctypes.bytearray_at

[GitHubsSilverBullet]

@peterhinch
Hmmm, does it truly allocate? It looks like it doesn't and using it for DMA asks for trouble.
One would have to allocate a much larger (byte)array-buffer and thus we're back at step 1.
What I was referring to was a function or method to allocate the correct amount of memory at a given address.

#!/micropython
# -*- coding: UTF-8 -*-
# vim: fileencoding=utf-8: ts=4: sw=4: expandtab:
import micropython
from array import array
from uctypes import bytearray_at

@micropython.asm_thumb
def adr(r0):
    pass

a,b,c = bytearray_at(0x20020000, 512),bytearray_at(0x20030000, 512),bytearray_at(0x20040000, 512)
for item in a,b,c:
    print(len(item), hex(adr(item)))
micropython.mem_info(1)
'''
512 0x20020000
512 0x20030000
512 0x20040000
stack: 540 out of 7936
GC: total: 224640, used: 5184, free: 219456
 No. of 1-blocks: 60, 2-blocks: 13, max blk sz: 64, max free sz: 13657
GC memory layout; from 20009280:
00000000: h=MhhhBDThBTTBDhTBDBBBh===DBDh====B=BBBBBBTB=BTB=BBBTB=TBTB=Bh==
00000400: =BB=h===========TB=h=h===================h=====AAAh=============
00000800: ====h===========================================================
00000c00: ====h===========================================================
00001000: ====h=hhhBh=hhhThT=hShShS.h=====................................
00001400: ....h=======h========...................h========h========...h=.
       (213 lines all free)
00036c00: ........................
'''

[Ludo-lab]

I think I am getting there thanks to your help:

 # ... initialization of PWM ...
# ....

TOP_ADDR = 0x40050000 + slice_idx * 0x14 + TOP_OFFSET
top_value =machine.mem32[TOP_ADDR] # get PWM slice

RING_SIZE = 2**8  # set the size of the buffer
_storage = bytearray(2 * RING_SIZE)

base = uctypes.addressof(_storage) # get base address

aligned = base & ~(511) # mask the last 9 bit

# make the buffer that aligned address
buffer = uctypes.bytearray_at(aligned, RING_SIZE*2)

# pack my sine as halfwords
for i in range(RING_SIZE):
    v = (math.sin(2 * math.pi * i / RING_SIZE + math.pi/2) + 1) * 0.5
    val = int(round(v * (top_value-1)))
    struct.pack_into('H', buffer, 2*i, val)

# DREQ for “PWM slice wrap”
DREQ_PWM_WRAP6 = 30 # DREQ_PWM_WRAP6

# calculate the ring_size
ring_size = int(math.log2(len(buffer)))

# Use the address for channel A (no offset), and ensure DMA is triggered
dma = rp2.DMA()
ctrl = dma.pack_ctrl(
    size=1,              # 1 = 16-bit transfers
    inc_write=False,     # always write to the same CC register
    inc_read=True,       # advance through the sine_buf
    ring_size=ring_size, # wrap at 2^ring_size bytes
    ring_sel=False,      # wrap the read address (sine_buf)
    treq_sel=DREQ_PWM_WRAP6
)

dma.config(
    read=buffer,
    write=CC_ADDR,
    ctrl=ctrl,
    count=0xFFFFFFFF, 
    trigger=True
)

Now the buffer is aligned (addressof(buffer) >>> 0x20008a00; addressof(buffer)%512 >>> 0 ).

However, still I get the same behaviour, that when I change the frequency of the sine, its shape change (see below)

Interestingly (?) if I run the main.py from my IDE (thonny or VSstudio) the sine is properly encoded, while if I upload the main.py to the pico, and I power it up I get this waveform:

[GitHubsSilverBullet]

base = uctypes.addressof(_storage) # get base address
aligned = base & ~(511) # mask the last 9 bit

That's very dangerous. ›aligned‹ will almost always be less than ›base‹.
You need to check and if it is less than ›base‹ you need to add half the buffersize.

aligned = aligned if aligned == base else aligned + 512

# make the buffer that aligned address
buffer = uctypes.bytearray_at(aligned, RING_SIZE*2)

Otherwise your DMA ring buffer points to somewhere before your allocated ›_storage‹

[peterhinch]

One possible source of confusion is that DMA is not stopped by a soft reset. I found I had to hard reset or power cycle the board. The answer is to explicitly stop it on exit.

[Ludo-lab]

Thanks @GitHubsSilverBullet and @peterhinch for the explanations!
I sedimented the information, and now the code works.

BUFFER_SIZE = 2**8  

placeholder = array('H', (0 for _ in range(512*2+2)))
_base = uctypes.addressof(placeholder) # get base address
_end_base = _base + len(placeholder)-1
_masked = _base & ~(511)
_offset = _masked + 512

buffer = uctypes.bytearray_at(_offset, BUFFER_SIZE*2)
for i in range(BUFFER_SIZE):
    v = (math.sin(2 * math.pi * i / BUFFER_SIZE + math.pi/2) + 1) * 0.5
    value = int(round(v * (top_value-1)))
    struct.pack_into('H', buffer, i*2, value)

_end_buffer = uctypes.addressof(buffer) + len(buffer)
assert _end_buffer < _end_base  # assert space allocation
assert uctypes.addressof(buffer)%512 == 0 # assert alignment