Stefan,
Having resource conflicts in a complex device while multiple things are running, this does happen in some cases like yours. There are limits to what you can do and there are improvements that can be done or at least tried.
[quote user="Anthony"]It might be worth to try to split the different EDMA0 transfers over TC0 and TC1.[/quote]
Specifically, put only the McBSP1 read transfer on EDMA0_TC0. Put all of the other transfers that have to be on EDMA0 on EDMA0_TC1. It was not obvious that you did this, since the SPI operation did not have the TCn specified.
Which memory endpoints are the other transfers using? Since your McBSP1 operation is writing to the internal Shared RAM, is this a common point for all the transfers and may be a stall point?
What data rates are you running the McBSP1, DSP and DDR?
Is the McBSP1 data a continuous stream? Do you get one FS per 16-bit sample? It could be helpful for throughput if you can get the incoming data as 32-bit words and store that data half as often.
[quote user="Stefan Hittmeyer"]EDMA is waiting for further McBsp RX events (PaRAM set not yet exhausted)[/quote]
The PaRAM you show at the end of your first post shows OPT.ABSYNC=1, ACNT=0x40, BCNT=1, CCNT=1. Whenever an event gets to the EDMA to read the RFIFO, it will read 0x40 bytes and then do a Link to 0x4880. There is nothing to see there that would indicate a "exhausted" state or not. It would be useful to see the EDMA0's IER, IFR, EMR, SEC, registers after the error condition has occurred, to add to the status you have already shown.
If you turn off only one of the processes 1, 2, and 3, does each of those 3 cases stop failing? Or is it only when you remove the process 2 to the NAND?
Do you have the facility to pulse different GPIOs at the start/end of each of the processes so you can see which one was coincident with the last successful McBSP1 read, or perhaps with the time when the next McBSP1 read should have occurred?
How much jitter do you have in your McBSP1 GPIO pulse? Does it always move around or does it tend to stay close to a fixed time after the 16th sample comes in, then jump a lot only during certain events? How much would that max jump be (same as jitter, maybe)?
If you turn off the EDMA0.IER bit for the McBSP1 Rx, will the freeze go away? I am curious if it is related to the DSP having to do anything.
Those are my ideas for now.
Regards,
RandyP