Some general questions about DMA and MicroPython

[JackCode0011]

Hello everyone,

I am working on a project where I am using SM and DMA and have encountered a few ‘problems’ for which I may need some confirmation or a second opinion:

Here is a brief overview so that you know what kind of figures we are dealing with:
_The state machine has a programme that allows me to collect a total of 15,360 bits. This happens 70 times per second. That's 1,075,200 bits or 134,400 bytes. That would be 1,050 times RX_FIFO (4 words) or 4,200 transfers with DMA with size=2.

From the description of the RP2350, I gather that the state machine can process 32 bits per clock cycle. At a frequency of 75 MHz, for example, that would be a total of 75,000,000 x 32 bits, which would be a total of 300,000,000 bytes. That's significantly more than I need. I work at 75 MHz, not to process so much data, but to capture all signal changes and not miss anything.

For DMA, I read that 100 MBytes/sec is possible as bandwidth across all channels. Since only one channel is ever active for me, this would be, hopefully correctly converted, 1,000,000 bytes per second. Significantly less than SM could deliver, but significantly more than I deliver._

Since I'm able to output the incoming data into bytearrays, which are a correct reproduction of the input without faults, I assume that I am therefore within the scope of what is possible. But unfortunately, there are a few problems or questions:

Question 1:

I have to following code:

... dma1 = rp2.DMA() dma2 = rp2.DMA() control1 = dma1.pack_ctrl(... chain_to=dma2.channel ...) control2 = dma2.pack_ctrl(... chain_to=dma1.channel ...) ...

With this code, DMA often doesn't start, or when it starts, the RP2350 crashes after around 5 seconds and I have to do a hard reset.
As far as I can see in the error, it crashes, because after a few switches between the two channels and collecting data without errors, I get the error message "dma1 / dma2 not defined". So, and I don't know why, it looses "assignment" during execution. And, if I let "normal" code run as well, that uses processor, I can see, that also other variables loose assignment. So it's not only a DMA problem per se.

Just to check I do:
print(dma1.channel) print(dma2.channel)

and I get dma1 = 0 and dma2 = 1

Now, if I change the code to this
control1 = dma1.pack_ctrl(... **chain_to=1** ...) control2 = dma2.pack_ctrl(... **chain_to=0** ...
everything is working as it should. Now, every example I have seen is working with chain_to=DMA.channel, so I'm a bit confused.
Am I missing something? The code is working wit DMA.channel, but as I said not very long, as it seems to loose the definitions. I have found another user question in the web, where the same question is asked. So is this maybe a bug?

Question 2:

When using Statemachine SM and DMA, I had the impression that the processor was not being utilised to full capacity. That is my understanding (SM and DMA run independently and do not require processor power). That is why I thought I could activate both and also run separate code at the same time. This works, but not for very long. After about 20 seconds, it usually starts to crash with various error messages indicating that there is no memory available. However, a check with gc.mem_free() shows that there is sufficient memory available. If I now deactivate DMA and read from the state machine with sm.get(), which requires the processor, the code runs smoothly even in the long term (although sm.get() is of course too slow to really follow the SM, so I need DMA).
What am I overlooking here? At first, see question 3.1 below, I thought that the byte array simply got bigger with each pass, but a check with gc.mem_free() shows that at the beginning, the free memory gets smaller when the byte arrays are filled for the first time, but after that, the memory remains constant (less than 30% used), which to me means that the byte array is overwritten each time. Nevertheless, I still get memory problems.

Question 3:

With dma1, I write to buffer1 = bytearray(320) and with dma2 to buffer2 = bytearray(320). This is certainly a beginner's question, but I am undecided and have not found a real answer. dma1 and dma2 each write 100x 32 bytes to the bytearray (thus 100 transfers with size=2). The bytearray is then full and it switches to the next DMA. When dma1 is active again, it writes to the same buffer1 and so on.

Question 3.1: Am I correct in thinking that the bytearray is overwritten from the beginning again? That would actually be the behaviour I want and the behavior I think I see. inc_write is set to true and, as far as I understand the RP2350 documentation, it should start from the beginning again when dma1 or dma2 is reactivated.

Question 3.2:
I am unable to retrieve data from the byte array during operation of DMA. I tried for example:
if dma1.active(): eval_buffer = buffer2 else: eval_buffer = buffer1
So while buffer1 is being written to by dma1, I make a copy of buffer2 into the evaluation buffer, and vice versa and then can work with the eval_buffer.
But i get the error, that the code is not able to make the operation. However, if I stop DMA completely first, I can execute eval_buffer = buffer1 or eval_buffer = buffer2 without any problems. Could it be that DMA is blocking the bytearrays, even if they are not currently the active DMA? I haven't tried it, but another idea I have is to use a third DMA3 to execute each of these copies. However, this would mean that the bandwidth would then have to be shared between the respective active DMAs.

Greetings and many thanks

[JackCode0011]

I almost forgot. Here the code. And I forgot the say, that with count= I have the same problem.
count=480 works
count=pack with pack=480 works
count=pack with pack=BUF_SIZE // 4 leads to crash after a few seconds, just as it happend with chain_to

This is just a "test-code" with the most essential functions for testing SM and DMA. My complete code is much more extensive, but since the problem also occurs here, the rest of the code is irrelevant.

import rp2, machine, time, gc

print(gc.mem_free())

BUF_SIZE = 1920
#pack = BUF_SIZE // 4 ### IF I USE THIS, DMA IS NOT WORKING. I HAVE TO USE pack = 480 OR INSERT 480 DIRECTLY!!!!
pack = 480
buffer1 = bytearray(BUF_SIZE)
buffer2 = bytearray(BUF_SIZE)

PIO0_BASE = const(0x50200000)
RXF0 = const(0x20)
DREQ_PIO0_RX0 = const(4)
BYTE_SIZE = const(2)

for i in range(5):
    machine.Pin(i, machine.Pin.IN)

@rp2.asm_pio(in_shiftdir=rp2.PIO.SHIFT_LEFT, autopush=True, push_thresh=32)
def prog():
    wrap_target()
    wait(1, gpio, 0)           # Wait for Pin0 = 1
    in_(pins, 4)                # Read in 4 bits from Pin1 to Pin4.
    wrap()

sm = rp2.StateMachine(0, prog, freq=75_000_000, in_base=machine.Pin(1))
sm.active(1)

dma1 = rp2.DMA()
dma2 = rp2.DMA()

ctrl1 = dma1.pack_ctrl(size=BYTE_SIZE, inc_read=False, inc_write=True, treq_sel=DREQ_PIO0_RX0, chain_to=1, enable=True, bswap=True)
ctrl2 = dma2.pack_ctrl(size=BYTE_SIZE, inc_read=False, inc_write=True, treq_sel=DREQ_PIO0_RX0, chain_to=0, enable=True, bswap=True)

# AS I WROTE, THE CODE IS ONLY WORKING WITH chain_to=1 OR 0, BUT NOT WITH chain_to=dma1.channel/dma2.channel.

dma1.config(read=PIO0_BASE+RXF0, write=buffer1, count=480, ctrl=ctrl1, trigger=True)
dma2.config(read=PIO0_BASE+RXF0, write=buffer2, count=480, ctrl=ctrl2, trigger=False)

# HERE AS WELL: count=pack, IN WHICH pack = BUF_SIZE // 4 IT'S NOT WORKING. I HAVE TO US pack WITH pack = 480 OR WRITE 480 DIRECTLY.

eval_buf = bytearray(1920)

print(gc.mem_free())

while True:
    if dma1.active():
        eval_buf = frame2
    else:
        eval_buf = frame1
    print(gc.mem_free())
    
#   [... here do something with eval_buf, and then back to the beginning to get the next buffer read. In the meantime SM and DMA are continously collecting and writing to buffer1 and buffer2.] 

[JackCode0011]

Hello

As we say in German: "Den Wald vor lauter Bäume nicht sehen." "Sometimes you just can't see the forest for the trees." Yes of course eval_buffer = frame1[:] is the correct way. After more than two weeks of trying to debug this code and starting to loose my mind, I suppose I just got lazy.

And yes, It doesn't make sense at all. The whole thing is not on a breadboard, but neatly soldered onto a circuit board. But since I also suspected that the signal might be interfering, I took the following steps:

I used a completely new Pi Pico out of the drawer and did not attach any signals at all. I adjusted the code so that it always evaluates 4 pins and does not wait for Pin0. I reduced the speed of the state machine so that there are still the same number of bits per second. This means that only zeros are evaluated, but the whole thing still has to work. And the DMAs have to switch to each other the same number of times per second.

And the result was that the problem occurred exactly the same.
I then assumed that it might be due to the software or laptop.
I tried two different laptops and a PC, each with PyCharm and Thonny, and got the same result everywhere.

So my current guess is that there is something in my code, which I added, that is causing this error, but I am overlooking it.

What confuses me is that when I take any code from Github with SM and DMA and try it out, everything works. But as soon as I change anything in the DMA (packet size, size, chain_to), it no longer works. So at the moment, I think I'm doing something wrong with the DMA configuration, but I can't see what it could be.

[GitHubsSilverBullet]

dma1.config(read=PIO0_BASE+RXF0, write=buffer1, count=480, ctrl=ctrl1, trigger=True)
dma2.config(read=PIO0_BASE+RXF0, write=buffer2, count=480, ctrl=ctrl2, trigger=False)

Here you activate the dma1 without having dma2 configured.
Sure that there's enough time between starting dma1, setting up dma2, finishing dma1 and chaining to dma2?

[JackCode0011]

Well, that is a good question. Often dma1 starts and then chains to dma2, and back again and that as I wrote for around 5 seconds, before crashing. In this 5 seconds a have valid data in both bytearrays. Considering the bits read per seconds, the arraysize and the packsize, the switch between dma1 and dm2 happens around 185 times before crashing. So, yes I think there should be enough time. But, while debugging the code I also thought that this could be the problem and I also tried to set both config to trigger= False and than afterwards tried dma1.active(1) or dma1.config(trigger=True). But even that way the problem is still there, so with the fact that the whole operation does work for some seconds, I was under the impression, that the way the channels are started should not be the cause of my problems.

[GitHubsSilverBullet]

happens around 185 times before crashing.

Right. After that amount of loops you've managed to successfully overwrite your entire memory.
Hint: Your DMA write address constantly increases without ever being reset to the buffer start (where it belongs)

DMA is a harsh mistress!

[JackCode0011]

You know what? You are my hero. Yes, that was the problem! Thank you very much for that hint!!!

That's why I asked:
Question 3.1: Am I correct in thinking that the bytearray is overwritten from the beginning again? That would actually be the behaviour I want and the behavior I think I see. inc_write is set to true and, as far as I understand the RP2350 documentation, it should start from the beginning again when dma1 or dma2 is reactivated.

The problem I had, and I just checked again: All the examples I have found with SM and DMA, that collect data continuously with two DMA chained to each other, have no way implementent in resetting the write adress. This, coupled with the documentation saying:

When transferring to/from a **consecutive** series of buffers in memory (e.g. scattering and gathering), an address
register will already have incremented to the start of the next buffer at the completion of a transfer.

Now, with your hint, I understand the documentation saying, that with the next transfer, the address is already incremented and ready for the next transfer (so the adress is higher). But, before your hint, and with all the examples with no resetting, I understood the documentation wrong in assuming they try to say, that with the next transfer the adress is already set to the correct value if you use a consecutive buffer (so, translated with deepl to German it tells me, that the adress is higher after each switch to the next buffer). Well, there is a difference in translation and understanding between "consecutive buffer" (would be two different bytearrays after another), "consecutive transfers" (so the switch to the next byte in the same bytearray) and "consecutive bytearrays", which I assumed would be the term for my case, so I assumed consecutive buffer is meant to be the next bytearray, when the cycle before is finished and restartet (trans_count = 0 and restarting), when in reality next buffer is meant to be the next byte in the bytearray. So, because I always write to buffer1 or buffer2 and not a consecutive buffer in my understanding of the translation, I just assumed with all the informations I got and examples, that in my case it's always the same buffer and therefore this statement in the documentation is not applicable to my use case, because yes the adress is higher after each transfer, it must be, because it would overwrite the start of the bytearray with each transfert, but not after each new start after trans_count = 0, which now I see that the documentation tries to tell. Well, you learn something new everyday!

So, yes, now I know the solution. Reset the write adress, or maybe checking a solution with ring_size. 2^11 would be 2048 bytes and close to 1920 Bytes so maybe with filling up to 2048 bytes every read cycle (and then just working with 1920 bytes) I would be able to loop back the adress without needing another channel to reset the adress. But, at least I can continue to work from here and see, which solution will be the best, but at least the code I have right now is running, when resetting the adress.

Again, many thanks for that hint and taking your time!!!

[GitHubsSilverBullet]

Good to see that you're working and improving on it. 👍
The DMA subsystem can issue IRQs after a finished transfer.
And in the callback routines one can easily reset the buffer addresses.
Works (tested) with several ten thousand IRQs per second.

[GitHubsSilverBullet]

For DMA, I read that 100 MBytes/sec

RP2350. A 400kB (400_000) bytearray.
DMA memory to memory transfer (first half to second half):

src: 20008a60 (200000)
dst: 200397a0 (200000)
CPU cycletime: 6.67 ns  (150 MHz)
 1535000 ns -> 7.675 ns/BYTE       666000 ns -> 3.330 ns/HALFWORD       334000 ns -> 1.670 ns/WORD     
 1519000 ns -> 7.595 ns/BYTE       668000 ns -> 3.340 ns/HALFWORD       334000 ns -> 1.670 ns/WORD     
 1518000 ns -> 7.590 ns/BYTE       667000 ns -> 3.335 ns/HALFWORD       334000 ns -> 1.670 ns/WORD     
 1519000 ns -> 7.595 ns/BYTE       667000 ns -> 3.335 ns/HALFWORD       333000 ns -> 1.665 ns/WORD     
 1519000 ns -> 7.595 ns/BYTE       667000 ns -> 3.335 ns/HALFWORD       333000 ns -> 1.665 ns/WORD     
MEM->MEM transfer speed: 572.777 MB/s

Not to bad, considering the maximum possible of 600 MB/s

[JackCode0011]

Wow, so it's much higher than the numbers I found. Which is positive, as there is even more margin between needed speed and maximum speed.