Problem overwriting buffer when using DAC.write_timed()

[LinderaG]

Hello!

I am using micropython on an STM32 Nucleo F767ZI and I am very new to this world (so I apologize in advance if this is a trivial problem).

I wrote a simple test code that creates and outputs a sinusoid from a DAC port.
In the main loop, every 5 seconds, the sinusoid is translated up or down by a fixed quantity by overwriting a buffer.
Here is the code:

import pyb

nSamples = 128
samplingRate = nSamples * 8
nucleoIsOn = True

dac = pyb.DAC(2, bits=8, buffering=False)
dacTimer = pyb.Timer(6, freq=samplingRate)
dacBuf = bytearray(nSamples)
dac.write_timed(dacBuf, dacTimer, mode=DAC.CIRCULAR)

while nucleoIsOn:
        
    pyb.LED(1).on()        
    for i in range(len(dacBuf)) :
        dacBuf[i] = 50 + int(20 * math.sin(2 * math.pi * i / len(dacBuf)))    
    pyb.delay(5000)
    pyb.LED(1).off()

    pyb.LED(2).on()        
    for i in range(len(dacBuf)) :
        dacBuf[i] = 100 + int(20 * math.sin(2 * math.pi * i / len(dacBuf)))    
    pyb.delay(5000)
    pyb.LED(2).off()

My issue is that the buffer does not seem to be correctly overwritten, as if some portion of the buffer still contain the previous sinosoid.

Edit: The previous sentence cannot actually be true. Apart from the fact that it would be a very weird behaviour, I also checked the buffer content after the overwriting by sending the data through a USART port, and the sinusoid looks good! Could it be more of a DMA/synchronization problem?

Or similarly, the buffer is overwritten, but what is continuously sent through the DMA is an "uncomplete" version of the new buffer.
The effect, as seen on a scope, is a "fragmented" sinusoid as shown in the example figures:

Some additional comments:

• The "zones" in which the fragmentation happens are different every time the buffer is overwritten. But within the 5 seconds, the periods are identical (featuring the same "pattern of fragmentation").
• When I unplug and re-plug the usb cable that I use to acces the flash memory (USB-OTG, CN13), the sinusoid is momentarily "fixed", just to be fragmented again on the next change. My guess is that usb plugging is triggering a hard reset on something but I don't know on what (the documentation does not say much about this).
• I have already tried re-initializing the timer after the overwriting but that does not change the behaviour.
• I have also tried to clear the buffer and re-create it, but that requires sending the dac.write_timed() command again, which still does not solve the problem (again, chaotic waveform).
• I have tried defining two different buffers with the two sinusoids and calling dac.write_timed(dacBuf1, dacTimer, mode=DAC.CIRCULAR) / dac.write_timed(dacBuf2, dacTimer, mode=DAC.CIRCULAR) alternatively in the loop. That seems to work! Which is why I identified this as a buffer overwriting issue.
• It is not a scope connection problem. I know this because I have tried connecting the DAC to one of the ADCs and sending the sinusoid to my pc through a USART connection. The effect is exactly the same.
• Micropython version: v1.23.0

What am I doing wrong?

Thank you in advance for your help!

Linda

[peterhinch]

There are three processes going on which are mutually asynchronous:

1. Writing of samples to the DAC.
2. Changing the buffer contents.
3. The scope timebase.

I am not surprised that the results are erratic.

I have tried defining two different buffers with the two sinusoids and calling dac.write_timed(dacBuf1, dacTimer, mode=DAC.CIRCULAR) / dac.write_timed(dacBuf2, dacTimer, mode=DAC.CIRCULAR) alternatively in the loop. That seems to work! Which is why I identified this as a buffer overwriting issue.

In this case the two buffers contain static content. You're starting and stopping write_timed in such a way that output starts synchronously with sample 0 being output first. The waveform will have one discontinuity caused by stopping one write_timed but the next starts on zero so the scope should be able to trigger reliably.

[LinderaG]

Hello @peterhinch ,

Thank you for your feedback!

I would leave the scope timebase out because I don't think it's causing any problem.

What I think is playing a role is indeed the synchronization between the buffer changing, the DMA accessing the buffer and the DAC writing.
It is not very clear to me how and when the DMA has access to the new buffer, since it is automatically managed. Is there a way to control this aspect in micropython?

For now I implemented a silly patch: I rewrite the buffer multiple times (2 was not enough, I am using 5 just to be sure) and that works fine.
Here's what I am doing:

for _ in range(5):
  for i in range(len(dacBuf)):
    dacBuf[i] = 50 + int(20 * math.sin(2 * math.pi * i / len(dacBuf)))

I guess this leaves the DMA enough time to understand that there is new content in the buffer and what this content is. Sorry if I talk "qualitatively" but I am no expert, I'm trying to guess.
Nonetheless, this is neither an efficient nor an elegant way to solve the issue, so I am open to suggestions!

Regarding what you said about the two static buffers: that is clear!
What still bugs me is: why is my output fragmented in multiple parts instead?
If it is a matter of starting from 0 or not, shouldn't I see the waveform "divided" in only two parts?

Thank you again.

Have a nice day,
Linda

[Bortania]

@peterhinch Can it be the issue with not properly managing D-Cache via DMA?
Similar to the issue here #13717

[peterhinch]

@LinderaG @Bortania This is overthinking the problem (IMO).

It is poor programming practice to have two asynchronous processes concurrently accessing the same buffer, where one process is changing the buffer contents. Applications should be designed so that this doesn't happen. There are many ways to do this. One is to use a pair of buffers: one task fills buffer 0 while the other reads buffer 1. When buffer 0 fills and buffer 1 becomes empty, the buffers are swapped. This is known as a 2-phase buffer, or ping-pong buffers. Another way is using a circular buffer which can be designed to be "thread safe": you can concurrently read and write, subject to constraints. The "best" approach is application dependent.

I can't explain the detail of the waveform. Alas I find it an unproductive use of my dwindling grey matter to probe the detailed behaviour of a system with a basic design issue. ;-)

[peterhinch]

The following works fine here

import pyb
import math
from time import sleep_ms

nSamples = 128
samplingRate = nSamples * 8  # 1024Hz

dac = pyb.DAC(2, bits=8, buffering=False)  # X6
dacTimer = pyb.Timer(6)
dacTimer.init(freq=samplingRate)
dacBuf = bytearray(nSamples)
trig = pyb.Pin('X1', pyb.Pin.OUT, value=0)  # Scope trigger

def send_synchronous(tms, led):
    led.on()
    trig(1)  # Trigger the scope
    trig(0)
    dac.write_timed(dacBuf, dacTimer, mode=dac.CIRCULAR)  # Restart at a zero crossing
    sleep_ms(tms)
    led.off()

def sample(i):
    return round(20 * math.sin(2 * math.pi * i / nSamples))

def populate(offset):
    for i in range(nSamples) :
        dacBuf[i] = offset + sample(i)

while True:
    t = 1000  # rep rate 1s
    populate(50)
    send_synchronous(t, pyb.LED(1))
    populate(100)
    send_synchronous(t, pyb.LED(2))

There is a discontinuity when the waveform changes but no strange waveforms as per the original post. The discontinuity is inevitable as the code is suddenly adding or subtracting a DC value from the sine wave, but it is minimised by starting the new sinewave at a zero crossing.

The key is to consider synchronisation, including the testgear.