CPU: 5535, CCS v4.2, CGTOOLS 4.3.9, BIOS: 5.41.13.42 Platform:5535ezdsp
We are having trouble with the aggregate DMA interrupt.
We have a SW system that is running the Codecs at 48Khz Stereo and streaming the adc data to an SD Card.
We are using the dmas for the rx/tx codec transfers and for the transfers of data to/from the sd card (mmc0), so we essentially have three dma sources that can create a CPU DMA Interupt.
dma1:ch0-3 are used for codec. dma0ch0 for sd writes, dm0ch1 for sd reads.
the dma_isr( ) is pretty straight forward, here is some psuedo code:
dma_isr()
{
ifrValue = CSL_SYSCTRL_REGS->DMAIFR;
CSL_SYSCTRL_REGS->DMAIFR = ifrValue; // clear/acknowledge all latched events imediately.
if (ifrvalue shows rx/tx codec event has happened)
{
service the rx/tx code interrupt
}
if (ifrvalue shows sd card event has happend)
{
service the sd card interupt.
}
}//done
The system runs fine for the most part, but after 1/2 to hour of continuous running, will suddenly just stop. By stop I mean we stop getting all dma interrupts.
When I halt the system with the emulator, this is what I see.
IER0: 0x0130 (dma int (0x0100) is enabled)
IFR0: 0xE010 (no DMA int pending).
DMAIFR = 0x00F0 (shows all 4 codec dma events have happened)
DMAIER = 0x00F0 (shows all 4 codec dma events are enabled).
So somehow the codec dma events failed to trigger a CPU DMA INTERUPT in the IFR0.
If I continue running the emulator, I see that the dmas are still running, and all my other threads are still running, its just that we have stopped getting the CPU DMA interrupt.
I put in observation variables at the end of my dma_isr( ) and I know that on occasion, while I am in the dma_isr for one type of dma event, a new DMAIFR bit has been set for one of the other events. In this situation, I see the the DMA interrupt bit of IFR0 is also set. Lets call this situation a latentDMA event. For example I might be servicing a sd event and I'll see at the end of the isr that a new DMAIFR bit is set for the codec dma event. I view this as a normal situation, as I expect upon exit of the dma_isr( ), once the DMA INT bit of IER0 is re-enabled, that it will generate another dma_isr to service this new one.
On even rarer occasion, I see at the end of my dma_isr( ) that a new DMAIFR bit has been set as described above, HOWEVER the DMA interupt bit of IFR0 is NOT set. Lets call this situation a missedDMA Event.
When the system breaks, is see that in the last dma_isr( ) a missedDMA Event occured.
However, a missedDMA Event didn't always break the system. For example in one run, out of 533535 dma isrs, there were 54 missed DMA events. The last one that occured broke the system. In that missed event, we were servicing the sd dma event when a new Rx codec dma event came in.
So something in the timing and/or mechanism of acknowledging the DAMIFR so that the next DMA event will trigger a CPU DMA INT is broken. Its seems I have done all one should do on the SW side of things: acknowledge the events that occured, service them, return.
Are there any known pipeline issues, silicon issues, SW bugs anything that can explain why the aggregate DMA interrupt architecture can ocassionaly fail if another DMA interupt comes in while we are in the dma_isr?
What is the timing of a DMAIFR bits being set to the eventually setting of the CPU DMA interrupt bit in IFR0? what is the silicon logic that determines when a new DMAIFR event will create a new CPU DMA INT?
Any help will be greatly appreciated.
-Shawn