PIO/SM and DMA crash when writing to file

[JackCode0011]

Hello everyone

I have here micropython-code, where I have a statemachine and two dma chained to each other writing to a bytearray. Now, the statemachine has a program collecting 15'360 bits, that get written to a bytearray by dma0. dma1 then retriggers dma0 with resetting the writeadress. These work without any problems, and I can check at regular intervals using print() that the state machine and DMA are active. When I print the byte array, I can also see that the values are being updated.

Everything works, and I'm happy.

However: when I attempt to write the contents of the byte array to a file, the file is created and the byte array is written to the file. But with a timer after 5 seconds, the next file should be written. However, this does not occur. When I check the state machine and DMA again using print() after creating the file, I observe that they are no longer active. So they are both deactivated or crash after or during creation of file. But the RP2350 itself does not crash or freez and the rest of the code, which can be executed without sm/dma is still being executed.

The error occurs regardless of whether I save the file to the flash memory or to the SD card.

Has anyone else noticed this behavior or has an idea, what could be the cause? Software or hardware?

Greetings

[GitHubsSilverBullet]

or has an idea, what could be the cause?

The RP2040 board runs on a default 125MHz clock while the RP2350 runs 150MHz.
What's the time period, or better, how fast are the buffers filled? Do the writes have enough time to complete?

[JackCode0011]

Well, I can change the speed and how many bits are collected.

• Maximum value would be 1'152'000 bits per second
• Minimum value would be 15'360 bits per second

In both cases everything works as intended, as long as I don't write to I file.
I have now reduced the writing to:

with open (file, "w") as f:
    f.write("Test")

With this reduced code, I can get two files to be written, and then DMA and SM crash. If I write two lines at once, it crashes after the first file being written.

So, as long as I don't write a file, everything is fine.
But, what I found out as well: Even, when DMA and SM are not crashing after writing a file, I see, that DMA and SM are not synchronised anymore. I have some more ideas (last ones), what I could try. Will get back here with results.

[JackCode0011]

Oh, damn it. You can waste hours and days troubleshooting, and then suddenly find the error in just a few attempts. The error was as follows. When reconfiguring DMA0 via DMA1, I determined the address as follows:
self.input_buffer_addr = uctypes.addressof(array.array('L',[uctypes.addressof(self.input_buffer)]))

However, it should be correct as follows:
self.input_buffer_addr = array.array('L',[uctypes.addressof(self.input_buffer)])

This ‘minor’ error caused the crashes. The code has now been running for around 30 minutes and has already written over 360 files without any errors or crashes.

And what have I learned from this? Don't just copy examples that work for other people. Why the incorrect address specification worked in various external examples (allegedly for other people) is not clear for me, but it was definitely the wrong way in my case.

And to show what else I found out in the last hour: As mentioned, SM and DMA did not crash without writing to the file. But upon checking again, I saw that the bits from the SM collection program were only written correctly from DMA to the buffer once. I just saw up until now, that the bytearray was different and asumed it was correctly updated. But from the second run onwards, the buffer was only partially updated because the address kept shifting. After around eight write cycles, the buffer stayed the same, as DMA was writting outside the buffer range. I now suspect that even without writing to the file, the crash would have occurred at some point, although later, as I now suspect a memory problem, since the shifting address would have overwritten the entire memory sooner or later. Writing to the file just sped up things.

A quick check with micropython.mem_info(1) (which I should have done sooner, but I only checked the overall free space, which was fine) shows, that indeed there was enough space, but scattered across many short blocks.