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.

[LinderaG]

Hello,

I can assure you that the scope trigger is not part of the issue: the scope is running continuously, while the sinusoid itself is used as trigger.

Here is what I measure when I use the code above (I just changed the amplitude and offset values for them to be compatible with not changing the scope trigger level):

glitching_wave.mp4

As you can see, sadly it is not working fine at all on my side. The discontinuities do not happen only at the change, but they are present at every period.

I also tried the approach of ping-pong buffers as you suggested: similar result.
In this case I am not changing the buffer while the DAC is reading from it.
While the DAC is reading from buffer_ping, I fill buffer_pong.
When the filling has finished, I call dac.write_timed from buffer_pong. And viceversa.

Here the code I used:

import pyb
import math

def populateAndSend(ping:bool, pong:bool,
                    dacBuf_ping, dacBuf_pong,
                    dac,
                    dacTimer,
                    offset):
    
    if ping: # if DAC writing from dacBuf_ping: fill dacBuf_pong, then write from it
        
        for i in range(len(dacBuf_pong)) :
            dacBuf_pong[i] = offset + int(30 * math.sin(2 * math.pi * i / len(dacBuf_pong)))
        
        dac.write_timed(dacBuf_pong, dacTimer, mode=pyb.DAC.CIRCULAR)
        
        pong = True
        ping = False
        
    elif pong: # if DAC writing from dacBuf_pong: fill dacBuf_ping, then write from it
        
        for i in range(len(dacBuf_ping)) :
            dacBuf_ping[i] = offset + int(30 * math.sin(2 * math.pi * i / len(dacBuf_ping)))

        dac.write_timed(dacBuf_ping, dacTimer, mode=pyb.DAC.CIRCULAR)
        
        ping = True
        pong = False
    
    return ping, pong


nSamples = 100
samplingRate = nSamples * 100  # 10000 Hz

dac = pyb.DAC(2, bits=8, buffering=True)  # X6
dacTimer = pyb.Timer(6)
dacTimer.init(freq=samplingRate)
dacBuf_ping = bytearray(nSamples)
dacBuf_pong = bytearray(nSamples)
ping = True 
pong = False


while True:
    
    t = 1000  # rep rate 1s
    
    for ledIndex, offset in zip([1,2,3], [60, 90, 120]):
        
        pyb.LED(ledIndex).on()
        ping, pong = populateAndSend(ping, pong,
                                    dacBuf_ping, dacBuf_pong,
                                    dac,
                                    dacTimer,
                                    offset)
        pyb.delay(t)
        pyb.LED(ledIndex).off()

I have also tried using not only 2 buffers but also 2 timers, same problem.
Another thing I have tried: using dacBuf_ping = bytearray(nSamples) to reset the buffer before filling it again. The behavior in this case is even worse:

glitching_wave_2.mp4

My question would be: how does the DMA access to the buffer happen? Is the DMA process making any copy of the buffer?
Because it looks like there is a copy of my buffer that is never correctly replaced.
Are there any DMA settings that I have not access to through micropython that are preventing data to flow in the expected way?

Thank you,
Linda

[Bortania]

@dpgeorge Sorry for tagging you here.
But we have issue with DAC on STM32 F767ZI. We think that maybe DMA has problem with cache.
We are not expert in MicroPython; Linda (see her comments above) made as details as possibile description of the issue.
Thank you for your help.

[peterhinch]

@LinderaG To address the issue of your waveform when running my code. How it should work (and how it does work on the Pyboard) is:

• The timer is triggered at 1024Hz.
• The buffer holds one cycle of a sinewave in 128 samples.
• Hence the frequency of the output sinewave is 1024/128 = 8Hz.
• The DC offset is applied after 1000ms and removed after another 1000ms (a frequency of 0.5Hz).
• Consequently 8 cycles are issued with offset 50 followed by 8 at offset 100.

Your scope trace shows a frequency of 79.72Hz which is ten times too high. The offset is being applied and removed four times per cycle, a frequency of 159.44Hz.

I'm afraid I'm stumped. I can't see how the code I presented can produce the frequencies you are observing. Unfortunately I don't have a Nucleo board so I can't replicate your test conditions exactly, but it seems that somehow the timing is wildly out.

Re DMA I haven't studied the source but feel free to do so.

I'm sorry I can't help further with this, but I'm out of ideas.

[LinderaG]

Hello,

You are correct, I have used 10 times the frequency you were using in your script, I forgot to specify it.
I have also tried using exactly your frequency though, and nothing changed.
What I also tried was waiting 500 ms, or even 1 s after replacing the buffer and before calling dac.write_timed, but no chance.

The offset is not being changed 4 times per cycle, that is exactly my point. If I zoomed out to visualize more periods, you would see that every period looks the same. The offset changes one time per second, exactly as you wrote in your script. In fact, in the first video, you can see a partial change in the offset every second. Nevertheless, within that second, the DAC is outputting the same "corrupt" data in a circular way. I hope I clarified what is happening.

That is why I believe it is not a problem of timing, or at least not exclusively. I still believe that there is some problem in how the DMA is accessing the RAM, as if it's registers are not pointing at the correct location.

You are right, I really should look into the source to understand if there are some settings that are not good for my application.
Thank you anyway for trying to help.

Linda

[peterhinch]

The fact that the code works as designed on a Pyboard but not on a Nucleo indicates a hardware/port specific issue. Hopefully someone who actually owns a Nucleo can assist.

[Bortania]

@peterhinch, what processor does Pyboard have? Cortex-M4 or Cortex-M7?

[peterhinch]

Cortex-M4 - STM32F405RG

[LinderaG]

Hello,

I have an update for this topic.
I tried to use a Pyboard and everything I was trying to do works just fine! I literally copy-pasted the same exact scripts, but did not see any corrupt sinusoid this time.

Not sure if the problem was with the Nucleo board or in the STM32F7.
I will try to debug some more and, in case, I will consider opening an issue.

Thank you again peterhinch for your help.

Best,
Linda