This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

PROCESSOR-SDK-OMAPL138: OMAPL138 underrun error in EDMA data transmition to mcasp XBUF.

Part Number: PROCESSOR-SDK-OMAPL138
Other Parts Discussed in Thread: TLV320AIC29, OMAPL138

Hello!

I'am using OMAPL138-C6748 Processor to finish the data transmition with EDMA by Peripheral configuration bus. MCASP finishes the data transmition with tlv320aic29 as the master device, and the EDMA uses the AB-synchronized transmition. The system runs normally at the beginning, but as the time goes on(maybe about two days later), the system runs abnormally with a underrun error in XSTAT register(the XUNDRN bit = 1, while the XDATA bit =1, too). At this time, EDMA doesn't transfer data anymore, and the CCNT register stays with the number neither the maximum count nor zero. And the receive sections of MCASP still works normally. The detial configuration of MCASP is listed as follows: Can  anybody help?

 // reset mcasp.

mcasp0regs->GBLCTL = 0;

// configure receive registers.

mcasp0regs->RMASK           = 0x0000FFFF;

mcasp0regs->RFMT              = 0x00018078;

mcasp0regs->AFSRCTL       = 0x00000102;

mcasp0regs->ACLKRCTL    = 0x00000029;

mcasp0regs->AHCLKRCTL = 0x00008004;

mcasp0regs->RTDM              = 0x00000001;

mcasp0regs->RCLKCHK      = 0x00FF0008;

mcasp0regs->REVTCTL       = 0x00000000;

// configure transmit registers.

mcasp0regs->XMASK           = 0x0000FFFF;  

mcasp0regs->XFMT              = 0x0001807C; //1-bit delay;MSB first;Slot size is 16 bits;Rotate right by 16 bit positions.

mcasp0regs->AFSXCTL       = 0x00000102; //2-slot TDM(I2S mode),Single bit,Internally-generated transmit frame sync, rising edge on transmit frame sync(AFSX)indicates the beginning of a frame

mcasp0regs->ACLKXCTL    = 0x00000029; //Rising edge,Single bit,Internal transmit clock source from output of programmable bit clock divider(CLKXDIV=0x09)

mcasp0regs->AHCLKXCTL = 0x00008004; //Internal transmit high-frequency clock source(HCLKXDIV=0x04)

mcasp0regs->XTDM              = 0x00000003; //Slot 0,1

mcasp0regs->RCLKCHK     = 0x00FF0008;

mcasp0regs->XEVTCTL       = 0x00000000; //Transmit data DMA request is enabled.

// config serializers (14= xmit, 15= rcv).

mcasp0regs->SRCTL14 = 0x00000001;

mcasp0regs->SRCTL15 = 0x00000002;

// config pin function and direction.

mcasp0regs->PFUNC  = 0;

mcasp0regs->PDIR   = 0x1C004000;

mcasp0regs->DITCTL = 0x00000000;

mcasp0regs->DLBCTL = 0x00000000;

mcasp0regs->AMUTE  = 0x00000000;

while ((0 == (mcasp0regs->GBLCTL & CSL_MCASP_GBLCTL_XHCLKRST_MASK)) || (0 == (mcasp0regs->GBLCTL & CSL_MCASP_GBLCTL_RHCLKRST_MASK)))

{

mcasp0regs->GBLCTL |= ((CSL_MCASP_GBLCTL_XHCLKRST_ACTIVE<<CSL_MCASP_GBLCTL_XHCLKRST_SHIFT) | (CSL_MCASP_GBLCTL_RHCLKRST_ACTIVE<<CSL_MCASP_GBLCTL_RHCLKRST_SHIFT));

}

while ((0 == (mcasp0regs->GBLCTL & CSL_MCASP_GBLCTL_XCLKRST_MASK)) || (0 == (mcasp0regs->GBLCTL & CSL_MCASP_GBLCTL_RCLKRST_MASK)))

{

mcasp0regs->GBLCTL |= ((CSL_MCASP_GBLCTL_XCLKRST_ACTIVE<<CSL_MCASP_GBLCTL_XCLKRST_SHIFT) | (CSL_MCASP_GBLCTL_RCLKRST_ACTIVE<<CSL_MCASP_GBLCTL_RCLKRST_SHIFT));

}

//enable the transmit and/ or receive interrupt

IER |= 0x4000;

edma_mcasp0rx_set();

edma_mcasp0tx_set();

//clear the respective transmitter and receiver status registers

mcasp0regs->RSTAT=0x0000FFFF;

task_delay();

mcasp0regs->XSTAT=0x0000FFFF;

//Take the respective serializers out of reset

while ((0 == (mcasp0regs->GBLCTL & CSL_MCASP_GBLCTL_XSRCLR_MASK)) || (0 == (mcasp0regs->GBLCTL & CSL_MCASP_GBLCTL_RSRCLR_MASK)))

{

        mcasp0regs->GBLCTL |= ((CSL_MCASP_GBLCTL_XSRCLR_ACTIVE<<CSL_MCASP_GBLCTL_XSRCLR_SHIFT) | (CSL_MCASP_GBLCTL_RSRCLR_ACTIVE<<CSL_MCASP_GBLCTL_RSRCLR_SHIFT));

}

while ((0 == (mcasp0regs->GBLCTL & CSL_MCASP_GBLCTL_XSMRST_MASK)) || (0 == (mcasp0regs->GBLCTL & CSL_MCASP_GBLCTL_RSMRST_MASK)))

 {

mcasp0regs->GBLCTL |= ((CSL_MCASP_GBLCTL_XSMRST_ACTIVE<<CSL_MCASP_GBLCTL_XSMRST_SHIFT) | (CSL_MCASP_GBLCTL_RSMRST_ACTIVE<<CSL_MCASP_GBLCTL_RSMRST_SHIFT));

}

//Take the respective frame sync generator(s) out of reset

while ((0 == (mcasp0regs->GBLCTL & CSL_MCASP_GBLCTL_XFRST_MASK)) || (0 == (mcasp0regs->GBLCTL & CSL_MCASP_GBLCTL_RFRST_MASK)))

{

mcasp0regs->GBLCTL |= ((CSL_MCASP_GBLCTL_XFRST_ACTIVE<<CSL_MCASP_GBLCTL_XFRST_SHIFT) | (CSL_MCASP_GBLCTL_RFRST_ACTIVE<<CSL_MCASP_GBLCTL_RFRST_SHIFT));

}

  • Hi,

    I've notified the RTOS team. They will post their feedback directly here.

    Please post the RTOS SDK version you are using.

    Best Regards,
    Yordan
  • Hello,

    Which SDK version are you using?

    Have you already referenced the initialization procedure listed in the Transmit/Receive Section Initialization section of the TRM?

    http://www.ti.com/lit/ug/spruh79c/spruh79c.pdf#page=1073

    There is a known issue where if any of the time slots within the n-slot TDM are inactive, random underrun errors may occur. See below:

    On all silicon revisions, in any McASP serializer configured a transmit serializer with an n-slot TDM, data transfer can fail if both of the conditions below are true:

    1. one or more time slots within the n-slot TDM are configured as inactive and

    2. EDMA is used to transfer data to McASP

    If the conditions mentioned above exists, either the transmit operation may fail to start with the XDATA bit in the Transmit Status Register (XSTAT) set or if the transmit operation has started, random underrun errors may occur breaking the data transfer operation.

    To ensure correct McASP transmit operation with EDMA triggered data transfers, all time slots in an n-slot TDM should be configured as active slots. For example, if a serializer is configured for transmit operation with a 5-slot TDM frame in which it is only required to transmit data in slots 0 to 2, all five slots (0 to 4) should be configured as active in the Transmit TDM Time Slot Register (XTDM). In this example the remaining time slots (slot 5 onwards) can be configured as inactive. The EDMA configuration and user application should account for the transfer of extra data to the McASP for slots 3 and 4.

    This is listed in the Silicon Errata: http://www.ti.com/.../sprz303h.pdf

    Best,

    Sahin

  • Sorry about the mistake I have make, may be I have chose a wrong Part Number. Because I don't know what the RTOS SDK version mean, the Compiler Environment (which is CCS3.3) or the development board. I use the DSP/BIOS system of 5.41.02.41 as the figure followes. If you don't mean this, can you give me a further explanation about that?

  • Hi,

    Firstly thanks for your reply. I shows the DSP/BIOS(5.41.02.14) version which I use in reply to Yordan Kovachev, I don't know if it is accurate . I have configured the mcasp according the initialization procedure in the Transmit/Receive Section Initialization section of the TRM. And I chose 2-slot TDM(I2S mode) with one transmit serializer in the transmit operation, both slots are configured as inactive. But I use EDMA to transfer data to McASP. So how to avoid the underrun errors in the data transfer operation?

    Then, I do not understand the example enough which you listed, the remaining time slots 3 and 4 need extera unuseful data to fill in? If I configure n-slot TDM, are all slots needed to be configured as active to avoid the underrun errors in the data transfer operation? Now I use 2 slots for I2S mode,and neither is inactive In the process.

    By the way, the linking of the Silicon Errata which is listed in the end can not be opened, can you send it again?

    Best Regards,
    Dahe
  • Hello Dahe,

    That's correct, all slots need to be configured as active to avoid an underrun error, and it is up to the user application to handle the extra data in slots 3 and 4.

    Sorry about the broken link, the errata can be found here: www.ti.com/.../sprz303h.pdf

    It is strange that underrun doesn't occur until two days after start of operation. Is there anything in your system that could cause an increase in latency? It seems like the EDMA is not transferring the data to the McASP in time.

    This thread had a similar issue, and it was resolved by disabling all printfs. Seems like an odd solution, but give that a try:
    e2e.ti.com/.../1676806

    Also, have you referred to the McASP examples provided in our software packages?
    C:\ti\OMAPL138_StarterWare_1_10_04_01\examples\lcdkOMAPL138\mcasp
    C:\ti\pdk_OMAPL138_1_01_00_02\packages\ti\drv\exampleProjects\MCASP_AudioExampleProject

    There is also sample code provided in this post:
    e2e.ti.com/.../1352229

    Regards,
    Sahin
  • Hi Sahin,

    I have tried to disable all printfs before, but it doesn't have any effect. I also doubt if It is that the EDMA can't transfer the data to the McASP in time, and I guess the error in EDMA data transmition may be caused by memory conflict.

    So I also tried another test: I have defined two new memories for ping-pong transmition by EDMA, and no other data processing can operate these two pieces of memory. Then if I disable all the data processing, the system runs normally and the underrun error doesn't occur. But if I keep the data processing alive, the underrun error occurs again as time goes on.

    I think the data processing can't influence the EDMA data transmition in this condition because the mcasp has its own clock, so I can't understand why the error appears again. There are no memory conflicts or processing timeout either. This problem is very odd and has troubled me for a long time. I do not know where the problem is.

    Since the random underrun errors may occur if EDMA is used to transfer data to McASP. Then on the premise of configuring all time slots in an n-slot TDM as active slots, how to avoid the underrun errors?
  • This is a really old version of the driver (2009-2011) and we don`t have the liberty to reach out to the developer to get an assessment for this underrun issue as this version of the driver is not actively maintained at this point in time. There was a similar issue reported at this time by a Japanese customer and you can look at the discussion with the developer on the E2E thread here:
    e2e.ti.com/.../391351

    you can look at the McASP Error register and take corrective action when the under run error occurs and if you are not using AFIFO, try to use EDMA to move data to the FIFO rather than the moving it directly into MCASP register. Another debugging technique would be to take a MCASP register dump when the device goes into underun error and compare it to initial clean state when you have data transmission to see if something changed in the MCASP setup.

    At this time for active support from TI, you will need to update to Processor SDK RTOS McASP driver as this version of the driver is not actively maintained by TI and is available for customers to use "as is"

    Regards,
    Rahul