Hi,
On our system we have the problem, that the McBsp1 FIFO stops generating EDMA3 RX events if there is kind of heavy traffic on EDMA3.
We use the McBsp for reception of data only and use the EDMA3_0 (Queue 0) in a “ping-pong” configuration reading those data out of McBsp1 FIFO into two shared-RAM sections. While there is nothing else happening than the McBsp + EDMA3 servicing the McBsp everything works like a charm. But if the EDMA3 has to service additional SPI events (RX & TX), QDMA data-transfers to the EMIFA (NAND-Flash) and the QDMA servicing ordinary 1d memcpy, the McBsp1 FIFO will stops generating RX events. However the McBsp1 will not immediately stop operation.
To me it looks like the EMIFA access is the central building block causing the issue because swapping all the data adressed to NAND-Flash to SDMMC module prevents the error-occurence. Please note, that also SDMMC module uses the EDMA0 for data-transfer.
In order to verify this problem not being selfmade, I created a “nutshell”-project reproducing this issue. This projects sets up the McBsp and EDMA3_0 for McBsp servicing. Subsequent to that, 3 processes will start to create the additional load on EDMA3_0 as followed:
Process 1 (testApl) keeps endless creating EDMA3-memcpy jobs (QDMA Queue 1)
Process2 (testApl2) keeps endless erasing one Flashblock and writeVerify this block (with QDMA support @ queue 1)
Process3 (testApl3) fills some random data into a buffer and sends this buffer to an SPI-Display (SPI RX/TX is also done with EDMA). SPI is running @ 20MHz
Each process places its job @ EDMA0 and waits for transfer-completion before placing a new order. On any successful McBsp1 completion Interrupt a port-pin is toggled for observation. However after a variable number of _minutes_ perfect operation, the McBsp stops. Checking the settings of McBsp and EDMA showed that EDMA is waiting for further McBsp RX events (PaRAM set not jet exhausted), McBsp->spcr says RFULL = 1 and RRDY=1 but the RFIFOSTS keeps static (not empty not full) which ends up in no further events generated. All other job such as EDMA3-memcpy, SPI xfers and nand-flashing keep working.
I tried to turn several optimization knobs such as busmaster-priority, default-burst-size, number of bytes per A-Dimension within PaRAM, moving events from queue0 to queue1 and vice versa. All those changes seem to impact the frequency of error occurrence, but none of those knobs could completely prevent the error.
Please see attached an export of all EDMA0 and McBsp registers while nominal (error-free) system conditions.
See below the McBsp, FIFO, and PaRAM4 setup after error occured:
((mcbsp_regs_t*) (0x01D11000)) struct mcbsp_s * 0x01D11000
*(((mcbsp_regs_t*) (0x01D11000))) struct mcbsp_s {...} 0x01D11000
drr unsigned int 0x00000002 0x01D11000
dxr unsigned int 0x00000000 0x01D11004
spcr unsigned int 0x02002031 0x01D11008
rcr unsigned int 0x00011040 0x01D1100C
xcr unsigned int 0x00000000 0x01D11010
srgr unsigned int 0x00000000 0x01D11014
mcr unsigned int 0x00000000 0x01D11018
rcere0 unsigned int 0x00000000 0x01D1101C
xcere0 unsigned int 0x00000000 0x01D11020
pcr unsigned int 0x00000081 0x01D11024
rcere1 unsigned int 0x00000000 0x01D11028
xcere1 unsigned int 0x00000000 0x01D1102C
rcere2 unsigned int 0x00000000 0x01D11030
xcere2 unsigned int 0x00000000 0x01D11034
rcere3 unsigned int 0x00000000 0x01D11038
xcere3 unsigned int 0x00000000 0x01D1103C
((mcbsp_fifo_regs_t*) 0x01D11800) struct mcbsp_fifo_s * 0x01D11800
*(((mcbsp_fifo_regs_t*) 0x01D11800)) struct mcbsp_fifo_s {...} 0x01D11800
bfiforev unsigned int 0x44311100 0x01D11800
rsvd0 unsigned int[3] 0x01D11804 0x01D11804
wfifoctl unsigned int 0x00001004 0x01D11810
wfifosts unsigned int 0x00000000 0x01D11814
rfifoctl unsigned int 0x00011001 0x01D11818
rfifosts unsigned int 0x00000007 0x01D1181C
*(&((edma3_pram_regs_t *)(0x01C04000))->pram_set4) struct unknown {...} 0x01C04080
opt unsigned int 0x80104004 0x01C04080
src unsigned int 0x01F11000 0x01C04084
acnt unsigned short 0x0040 0x01C04088
bcnt unsigned short 0x0001 0x01C0408A
dst unsigned int 0x8000164C 0x01C0408C
src_bidx short 0x0000 0x01C04090
dst_bidx short 0x0040 0x01C04092
link unsigned short 0x4880 0x01C04094
bcntrld unsigned short 0x0001 0x01C04096
src_cidx short 0x0000 0x01C04098
dst_cidx short 0x0024 0x01C0409A
ccnt unsigned short 0x0001 0x01C0409C
rsvd unsigned short 0x0000 0x01C0409E
While searching the e2e for any existing information on this issue I found the following, potentially unsolved post which seams like exactly the same issue:
http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/112/t/217915.aspx
Cheers
Stefan