EDMA connected to McBSP fails at extreme temperatures

Here is some more information about how the McBSP and EDMA is initialized:

init()

{

   // Disable multichannel feature
   McBSP1_MCR = 0x00000000;
   McBSP1_RCERE0 = 0x00000000;
   McBSP1_RCERE1 = 0x00000000;
   McBSP1_RCERE2 = 0x00000000;
   McBSP1_RCERE3 = 0x00000000;
   McBSP1_XCERE0 = 0x00000000;
   McBSP1_XCERE1 = 0x00000000;
   McBSP1_XCERE2 = 0x00000000;
   McBSP1_XCERE3 = 0x00000000;
     
   McBSP1_SPCR = 0;
   McBSP1_SPCR = McBSP1_SPCR & ~RRST;
   McBSP1_SPCR = McBSP1_SPCR & ~XRST;
   McBSP1_SPCR = McBSP1_SPCR & ~FRST;
   McBSP1_SPCR = McBSP1_SPCR & ~GRST;
   
   McBSP1_SPCR = FREE | RINTM_NEWFRM;
   /* Configure the PCR, RCR, and XCR regs */
   McBSP1_RCR  = RWDLEN1_32BIT | RWDLEN2_32BIT;
   McBSP1_XCR  = XWDLEN1_32BIT ;
   // clock mode (CPU derived) | clock divisor | frame size in clocks
   McBSP1_SRGR = CLKSM | 2 | (31 << 16);  
   McBSP1_PCR  = FSXM | CLKXM | CLKXP | CLKRP;
   
   for(i=0;i<100;i++); //Wait for configuration to finish
   
   // set up to receive a single 32 bit word whose value is the size of 
   // the frame to follow

static uint32 McBSP1_Rx_ByteCount = INVALID_PAYLOAD_SIZE;



   EDMA_RxSetup1D(EDMA_REVT1, 
                 (void *)&McBSP1_DRR,
                 &McBSP1_Rx_ByteCount,
                 sizeof(McBSP1_Rx_ByteCount));
   
   // This is trigger event that allows DMA to read from the McBSP FIFO
   // in a flow-controlled fashion.  It is a signal to the EDMA 
   // transfer controller logic that asserts on completion of every element 
   // (in this case an element is a 32-bit word)
   EERL  |= (1 << EDMA_REVT1);

   // Enable edma channel interrupt 15 for receive complete.
   CIERL |= (1 << RINT1);

   // This is trigger event that allows DMA to feed the McBSP FIFO
   // in a flow-controlled fashion.  It is a signal to the EDMA 
   // transfer controller logic that asserts on completion of every element 
   // (in this case an element is a 32-bit word)
   EERL  |= (1 << EDMA_XEVT1);
        
        // enable receive for McBSP1.
   McBSP1_SPCR |= RRST | GRST | XRST | FRST;

}

///////////////////////////////////////////////////////////////////////////////
// 1D array to transfer.  
// Element size is 32 bits.  
// Source address does not increment (it is the Data read register fo McBSP1)
// Numbers of DWORDS to transfer is McBSP1_Rx_ByteCount
// Destination address increments
// Generate and interrupt on completion.  Completion code is EDMA_EVT1
// No chain to other DMA descriptors
///////////////////////////////////////////////////////////////////////////////
void EDMA_RxSetup1D(uint32 hwEvent, const void* src, void* dst, uint32 bytes)
{
   uint32 *paramPtr;
   uint32 count = (bytes + 3)>>2;

   /* Setup Rx DMA PaRAM, Channel Map (Tx/Rx) and Enable Rx */
   paramPtr = PARAM_EVT_BASE_ADDR(hwEvent);
   *paramPtr++ = PRI_HIGH|ESIZE_32BIT|SUM_FIXED|DUM_INC|TCINT|
                          ((hwEvent & 0x0F) << TCC)|LINK;
   *paramPtr++ = (uint32)src;  
   *paramPtr++ = count; 
   *paramPtr++ = (uint32)dst;
   *paramPtr++ = 0;      
   *paramPtr++ = (uint32)EDMA_SDINT0_PTR & 0x0000FFFF;
}

Dean Harken said:

We are having a problem with our use of EDMA to read data from McBSP1 on the C6416.  This occurs infrquently at room temperature and very frequently at very low or very high temperatures.

Dean,

     What is the frequency of the events from the McBSP?

Dean,

Can you dump Param 15 (REVT1) just after you've configured it but before the McBSP is enabled?  Also, please dump it when you encounter this issue.  I want to verify that nothing has been corrupted and also see if the EDMA "thinks" it has already transferred something, i.e. has the count decremented.

Thanks,
Brad

Here is PaRAM 15.  These values are the same both before and after the first word arrives into the McBSP1 DRR.  Note that in this experiment, the McBSP is enabled before the DMA is configured but we have tried enabling McBSP both before and after EDMA is configured and the resulting behavior are the same. 

starting at address 0x01a0 0168:

0x203f 0002 

0x0190 0000

0x0000 0001

0x000c 6938

0x0000 0000

0x0000 0048

Thanks,

Dean

The problem happens on the very first message sent over McBSP and there is only one message being attempted at that time.

Thanks,

Dean

Thanks for the info.  Based on the fact that the parameter set has not updated I would conclude that the McBSP never sent an event to the EDMA, which is strange.  Can you provide some more detail about how you are testing this?  For example:

• Do you power cycle the board every single time?  Are the rails ramping all the way down between power cycles?  How much time are you giving it between runs?  Does this affect the outcome?
• Are you using CCS to do this testing?
  • Do you simply "restart" in CCS?
  • Do you perform any kind of reset between runs, e.g. disconnect, reset, connect, reload, run?
  • Are you using a gel file?

We have been able to decrease but eliminate the occurance of this problem.

The EDMA transfer controller was getting stuck.  We lessened to the problem by creating an Core power then IO power sequencing.  We were powering them on simultaneously and this was incorrect.

The McBSP was configured properly (we revised the init routine shown in an earlier post in this thread based on the instructions in TMS320C6000 DSP McBSP spru580g.pdf.  We would see data come in on McBSP and see the DRR1 register from within CCS and see the value in the register.  The EDMA PaRAM was being executed and we could see it load in the linked PaRAM set (all zeros in our case) and this was a reliable indicator of the DMA channel controller operation completion.  Consistent with the previous point, we could also see that the REVT1 event was getting signaled to the EDMA.  We determined that the DMA transfer controller was stuck because the PQSR was showing a non-empty condition for the priority queue that we were using. This was consistent with the condition that the contents of DRR1 never got copied to memory.  It seemed that there is no way to reset the DMA independently of the CPU.  We tried resetting the whole CPU and we found that the DMA would still get stuck.  Only changing the power supply sequencing helped.

Edit: This did not solved our problem completely and I removed incorrect errata title references.  Please see the next post for more details that we have discovered related to EDMA interrupts.

The power sequencing I mentioned in the previous post has not fixed our problem completely.  It has helped but not fixed it. 

I do have 3 new clues that perhaps someone with deep knowledge of the interrupt logic might be able to make use of.

1) I have found that if set up my EDMA transfers to not generate an interrupt, then the transfer no longer gets stuck in the transfer controller. I.e. the data is moved from McBSP DRR1 to memory and the PQSR shows an empty state.

2) When I set the EDMA transfer to be like 1), I occasionally get a "phantom" interrupt on the EDMA_ISR even though the EDMA controller is clearly not signalling an interrupt. I had accidentally left EDMA_INT set in position 10 of the MUXH register for this experiment and noticed that the ISRcount would be 1 every once in a while.

3) I have had some mysterious missing interrupts with GPIO edge detection that I could not explain. This was not a temperature dependent phenomenon, but it was relatively easy to reproduce.

Do you think that there could be something affecting our interrupt logic? Some noise on the board? Ringing somewhere? Is there someone at TI who knows the internals of the interrupt logic of the 6416T who might take a look at this information and see a pattern?

Thanks,

Dean