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.

RTOS/AM5728: MCASP3 RX overrun and sync errors

Part Number: AM5728


Tool/software: TI-RTOS

Hi,

On my device, in DSP1 core, I am trying to setup MCASP3 RX and TX in 32 bit, 8 slot TDM, sync mode with bit clock 24.576MHz / 96KHz frame sync (internal). DSP1 core (MCASP3) is setup as clock master for another external device. 

  1. When I only configure TX for MCASP3, I am see audio data coming out from the MCASP3_AXR0 as expected, with no errors.
  2. When I enable RX, I see overrun error with unexpected frame sync error. 
    1. The mcaspBindDev and  mcaspCreateChan dont return any error.
The callback passed to the mcaspCreateChan for MCASP3 RX is never being called by the driver after priming the RX and TX buffers.
  1. However, I do see callback happening for the TX
  • I verified the pin mux/ pad IO setup
  • The buffers are allocated on the L2SRAM
  • I am aware of the errata i868, and have tried different values for the hwFifoEventDMARatio

The MCASP3 setup configuration is as follows - 

{ /* MCASP3_TX */
0xFFFFFFFF, // MCASP_TXMASK
0x000080F0, // MCASP_TXFMT // Slot size = 32 bits, no bit delay
0x00000413, // MCASP_TXFMCTL
0x000000FF, // MCASP_TXTDM
0x0000000F, // MCASP_EVTCTLX
0x000001FF, // MCASP_TXSTAT
0x00000000, // MCASP_XEVTCTL
    {
         0x00000020, // MCASP_ACLKXCTL // CLKDIV = 1
         0x0000800F, // MCASP_AHCLKXCTL // HDIV = 16
         0x00000000 // MCASP_TXCLKCHK
     }
},
{ /* MCASP3_RX */
0xFFFFFFFF, // MCASP_RXMASK
0x000080F0, // MCASP_RXFMT // Slot size = 32 bits, no bit delay
0x00000413, // MCASP_RXFMCTL
0x000000FF, // MCASP_RXTDM
0x0000000B, // MCASP_EVTCTLR
0x000001FF, // MCASP_RXSTAT
0x00000000, // MCASP_REVTCTL
    {
         0x00000020, // MCASP_ACLKRCTL // CLKDIV = 1
         0x0000800F, // MCASP_AHCLKRCTL // HDIV = 16
         0x00000000 // MCASP_RXCLKCHK
     }
},

This is the dump of all status register using "omapconf dump mcasp3"

|--------------------------------------------|
| Reg. Name | Reg. Addr | Reg. Val. |
|--------------------------------------------|
| MCASP_PID | 0x48468000 | 0x44307B03 |
| PWRIDLESYSCONFIG | 0x48468004 | 0x00000001 |
| MCASP_PFUNC | 0x48468010 | 0x00000000 |
| MCASP_PDIR | 0x48468014 | 0xFC000001 |
| MCASP_PDOUT | 0x48468018 | 0x00000000 |
| MCASP_PDIN | 0x4846801C | 0x08000000 |
| MCASP_PDCLR | 0x48468020 | 0x00000000 |
| MCASP_GBLCTL | 0x48468044 | 0x0000031F |
| MCASP_AMUTE | 0x48468048 | 0x00000000 |
| MCASP_LBCTL | 0x4846804C | 0x00000000 |
| MCASP_TXDITCTL | 0x48468050 | 0x00000000 |
| MCASP_GBLCTLR | 0x48468060 | 0x0000031F |
| MCASP_RXMASK | 0x48468064 | 0xFFFFFFFF |
| MCASP_RXFMT | 0x48468068 | 0x000080F0 |
| MCASP_RXFMCTL | 0x4846806C | 0x00000413 |
| MCASP_ACLKRCTL | 0x48468070 | 0x00000020 |
| MCASP_AHCLKRCTL | 0x48468074 | 0x0000800F |
| MCASP_RXTDM | 0x48468078 | 0x000000FF |
| MCASP_EVTCTLR | 0x4846807C | 0x0000000B |
| MCASP_RXSTAT | 0x48468080 | 0x00000177 |
| MCASP_RXTDMSLOT | 0x48468084 | 0x00000000 |
| MCASP_RXCLKCHK | 0x48468088 | 0x00000000 |
| MCASP_REVTCTL | 0x4846808C | 0x00000000 |
| MCASP_GBLCTLX | 0x484680A0 | 0x0000031F |
| MCASP_TXMASK | 0x484680A4 | 0xFFFFFFFF |
| MCASP_TXFMT | 0x484680A8 | 0x000080F0 |
| MCASP_TXFMCTL | 0x484680AC | 0x00000413 |
| MCASP_ACLKXCTL | 0x484680B0 | 0x00000020 |
| MCASP_AHCLKXCTL | 0x484680B4 | 0x0000800F |
| MCASP_TXTDM | 0x484680B8 | 0x000000FF |
| MCASP_EVTCTLX | 0x484680BC | 0x0000000F |
| MCASP_TXSTAT | 0x484680C0 | 0x00000008 |
| MCASP_TXTDMSLOT | 0x484680C4 | 0x0000017F |
| MCASP_TXCLKCHK | 0x484680C8 | 0x56595300 |
| MCASP_XEVTCTL | 0x484680CC | 0x00000000 |
| MCASP_CLKADJEN | 0x484680D0 | 0x00000000 |
| MCASP_XRSRCTL0 | 0x48468180 | 0x00000011 |
| MCASP_XRSRCTL1 | 0x48468184 | 0x00000022 |
| MCASP_XRSRCTL2 | 0x48468188 | 0x00000000 |
| MCASP_XRSRCTL3 | 0x4846818C | 0x00000000 |
| MCASP_WFIFOCTL | 0x48469000 | 0x00000401 |
| MCASP_WFIFOSTS | 0x48469004 | 0x00000000 |
| MCASP_RFIFOCTL | 0x48469008 | 0x00010401 |
| MCASP_RFIFOSTS | 0x4846900C | 0x00000040 |
|--------------------------------------------|

And, omapconf show mcasp3 - 

|---------------------------------------------|
| Data Ports and Buffers |
|---------------------------------------------|
| Port | DATA bus |
| Transmit DMA | |
| DMA request | Enabled |
| Status | No error |
| Receive DMA | |
| DMA request | Enabled |
| Status | No error |
| Transmit Buffer (XBUF) | |
| Status | No error |
| Receive Buffer (RBUF) | |
| Status | Overrun occurred |
| Write FIFO (WFIFO) | |
| State | Disabled |
| Threshold | 4 samples |
| Level | 0 samples in FIFO |
| Read FIFO (RFIFO) | |
| State | Enabled |
| Threshold | 4 samples |
| Level | 64 samples in FIFO |
|---------------------------------------------|

|----------------------------------------|
| Control |
|----------------------------------------|
| Transmit State-Machine | |
| State | Held in reset |
| Transmit Sequencer | |
| Enabled Slots | 8 |
| Active Slots | 8 |
| Active Slots Mask | 0x000000FF |
| Current Slot | Inactive |
| Receive State-Machine | |
| State | Active |
| Receive Sequencer | |
| Enabled Slots | 8 |
| Active Slots | 8 |
| Active Slots Mask | 0x000000FF |
| Current Slot | 0 |
|----------------------------------------|

|-----------------------------------------------------|
| Clocks |
|-----------------------------------------------------|
| Transmit Bit Clock | |
| State | Running |
| Divider | Divide-by 1 |
| Source | Internal |
| Polarity | Driven on rising edge |
| Transmit High-Speed Clock | |
| State | Running |
| Divider | Divide-by 16 |
| Source | Internal (AUXCLK) |
| Polarity | Non-inverted |
| Receive Bit Clock | |
| State | Running |
| Divider | Divide-by 1 |
| Source | Internal |
| Polarity | Samples on falling edge |
| Sync Mode | Synchronous to TX |
| Idle Mode | No-idle |
|-----------------------------------------------------|

|----------------------------------------------------|
| Frame Sync Generator |
|----------------------------------------------------|
| Transmit Frame Sync | |
| Generator State | Held in reset |
| Source | Internal |
| Polarity | Frame starts on falling edge |
| Pulse Width | Single word |
| Slot Count | 8 (TDM) |
| Data Delay | 0-bit |
| Status | No error |
| Receive Frame Sync | |
| Generator State | Active |
| Source | Internal |
| Polarity | Frame starts on falling edge |
| Pulse Width | Single word |
| Slot Count | 8 (TDM) |
| Data Delay | 0-bit |
| Status | Unexpected frame sync |
| Sync Mode | Synchronous to TX |
|----------------------------------------------------|

|----------------------------------------|
| Format Units |
|----------------------------------------|
| Transmit Format Unit | |
| Slot Size | 32 bits |
| Bit Mask | 0xFFFFFFFF |
| Padding | Pad with 0 |
| Right-Rotation | 0 bit positions |
| Bitstream Order | MSB first |
| Receive Format Unit | |
| Slot Size | 32 bits |
| Bit Mask | 0xFFFFFFFF |
| Padding | Pad with 0 |
| Right-Rotation | 0 bit positions |
| Bitstream Order | MSB first |
|----------------------------------------|

|---------------------------------|
| Serializers |
|---------------------------------|
| Transmit Serializers | Cleared |
| Receive Serializers | Active |
| Serializer 0 | |
| Mode | Transmit |
| Inactive State | Hi-Z |
| Serializer 1 | |
| Mode | Receive |
| Inactive State | Hi-Z |
| Serializer 2 | |
| Mode | Inactive |
| Inactive State | Hi-Z |
| Serializer 3 | |
| Mode | Inactive |
| Inactive State | Hi-Z |
|---------------------------------|

|--------------------------------------------|
| Pin Control |
|--------------------------------------------|
| AFSR | |
| Functionality | Receive Frame Sync |
| Direction | Output |
| ACLKR | |
| Functionality | Receive Bit Clock |
| Direction | Output |
| AFSX | |
| Functionality | Transmit Frame Sync |
| Direction | Output |
| ACLKX | |
| Functionality | Transmit Bit Clock |
| Direction | Output |
| AHCLKX | |
| Functionality | Transmit High-Freq Clock |
| Direction | Output |
| AXR0 | |
| Functionality | TX/RX Data Channel 0 |
| Direction | Output |
| AXR1 | |
| Functionality | TX/RX Data Channel 1 |
| Direction | Input |
| AXR2 | |
| Functionality | TX/RX Data Channel 2 |
| Direction | Input |
| AXR3 | |
| Functionality | TX/RX Data Channel 3 |
| Direction | Input |
|--------------------------------------------|

  • And, the Mcasp_ChanParams is set as -


    { /* MCASP3_TX */
    1,
    { Mcasp_SerializerNum_0 },
    &mcasp_setup[MCASP3_TX],
    TRUE,
    Mcasp_OpMode_TDM,
    Mcasp_WordLength_32,
    NULL,
    0,
    NULL,
    (Mcasp_GblCallback)M3_GblErrXmt,
    8,
    Mcasp_BufferFormat_1SER_MULTISLOT_INTERLEAVED,
    TRUE,
    4,
    TRUE,
    Mcasp_WordBitsSelect_MSB
    },
    { /* MCASP3_RX */
    1,
    { Mcasp_SerializerNum_1 },
    &mcasp_setup[MCASP3_RX],
    TRUE,
    Mcasp_OpMode_TDM,
    Mcasp_WordLength_32,
    NULL,
    0,
    NULL,
    (Mcasp_GblCallback)M3_GblErrRcv,
    8,
    Mcasp_BufferFormat_1SER_MULTISLOT_INTERLEAVED,
    TRUE,
    4,
    TRUE,
    Mcasp_WordBitsSelect_MSB
    }
  • Jimit,

    Do you use AM57x PSDK RTOS v5.02?

    Do you use AM572x TI board (EVM, IDK) or custom board?

    Regards,
    Pavel
  • Pavel,

    I am using the AM57x PSDK RTOS v5.02 on custom board with TI-RTOS on DSP and M4 cores, Linux on A15 cores.

    Regards,
    Jimit
  • Jimit,

    So you have overrun condition when start to capture audio data on the AM572x McASP AXR input pin, is that correct?

    When DMA/CPU (DSP1) receives, data must be read from each serializer configured as active (active slot selected in MCASP_RXTDM ) and receive (Rx enabled in MCASP_XRSRCTLn ) within each time slot. Failure to do results in a buffer overrun condition. For details see AM572x TRM section "24.6.4.15.2 Buffer Overrun Error-Receiver" and "24.6.4.15.4 DATA Port Error - Receiver"

    Check also if you are aligned with errata "i933 Access to IODELAY at Same Time as Other Peripheral on L4_PER2 Can Hang"

    Regards,
    Pavel
  • Hi Pavel,

    I got only one RX serializer. I see overrun and unexpected frame sync error when I submit Rx buffer to MCASP driver using mcaspSubmitChan(). The MCASP_TiomCallback function registered with the mcaspCreateChan() doesn't get invoked after the RX buffer is submitted. I would expect the callback function to notify the application that the data is received - but that's not happening. (I have MCASP4 and 5 working just fine.)

    As to receiving the samples from the data port from serializer within each time slot and putting that into the buffers submitted - isn't that part of the MCASP drivers / pdk library?

    Regards,

    Jimit

  • I verified that all access to IODELAY is done before the MCASP buses are set up. I am still seeing same errors.

    Regards,
    Jimit
  • Jimit,

    Can you also made register dump of the McASP3 pinmux registers and provide me the values? There might be something wrong in your pinmux settings. Note that pinmux should be done in internal on-chip ram memory.

    Regarding mcaspSubmitChan() and mcaspCreateChan() functionality, you can get more info from the below document:

    pdk_am57xx_1_0_13/packages/ti/drv/mcasp/docs/MCASP_LLD_SDS.pdf

    Regards,
    Pavel
  • Hi Pavel,

    This is what I have for MCASP3 pins - 

    REGISTER NAME ADDRESS VALUE
    CTRL_CORE_PAD_MCASP3_ACLKX 0x4A003724 0x00010000
    CTRL_CORE_PAD_MCASP3_FSX 0x4A003728 0x00010000
    CTRL_CORE_PAD_MCASP3_AXR0 0x4A00372C 0x00010000
    CTRL_CORE_PAD_MCASP3_AXR1 0x4A003730 0x00050000

    Regards,

    Jimit

  • Jimit,

    mcasp3_aclkx is set as output only. Can you change it to in/out (rx enable) and check if that will make any improvement. For more details, refer to AM572x TRM, section 24.6.2.1 McASP Signals.

    NOTE: For the mcaspx_aclkx, mcaspx_ahclkx and mcaspx_aclkr signals to work properly, the INPUTENABLE bit of the appropriate CTRL_CORE_PAD_x registers should be set to 0x1 because of retiming purposes.

    Regards,
    Pavel
  • Pavel,

    I tried changing the pinmux for MCASP3_ACLKX to enable input in u-boot, but still seeing same issue.

    Pinmux in uboot -
    {MCASP3_ACLKX, (M0 | PIN_INPUT)}, /* mcasp3_aclkx.mcasp3_aclkx */
    {MCASP3_FSX, (M0 | PIN_OUTPUT)}, /* mcasp3_fsx.mcasp3_fsx */
    {MCASP3_AXR0, (M0 | PIN_OUTPUT)}, /* mcasp3_axr0.mcasp3_axr0 */
    {MCASP3_AXR1, (M0 | PIN_INPUT)}, /* mcasp3_axr1.mcasp3_axr1 */

    Regards,
    Jimit
  • Jimit,

    In which file exactly you are making this pinmux? For more info regarding AM57x RTOS pinmux, refer to the below pointers:

    www.ti.com/.../sprac44a.pdf
    software-dl.ti.com/.../index_board.html

    Note also that we have McASP example that you can refer to - MCASP_Audio_evmAM572x_c66ExampleProject. This example starts with receiving audio on the mcasp3_axr1 pin from AIC3104 codec and transfer that audio from AM572x McASP3 to AM572x DSP core. AIC3104 codec gets audio data from PC line output.

    You can explore the below fiels for reference:

    pdk_am57xx_1_0_13/packages/ti/drv/mcasp/example/evmAM572x/src/audio_evmInit.c
    pdk_am57xx_1_0_13/packages/ti/drv/mcasp/example/evmAM572x/src/mcasp_cfg.c

    pdk_am57xx_1_0_13/packages/ti/drv/mcasp/example/src/audioSample_main.c
    pdk_am57xx_1_0_13/packages/ti/drv/mcasp/example/src/audioSample_io.c

    pdk_am57xx_1_0_13/packages/ti/drv/mcasp/soc/am572x/mcasp_soc.c

    For more info regarding this McASP example, refer to the below user guide:

    software-dl.ti.com/.../index_device_drv.html

    Regards,
    Pavel
  • Pavel,

    I am making the pinmux in the uboot's mux_data.h. I can verify the pinmux being set correctly in uboot from userspace using omapconf tool.

    I have used EVM's MCASP_Audio_evmAM572x_c66 example project as reference for the implementing MCASP3/4/5 for custom board. Note that MCASP4 and 5 work, and so does MCASP3's TX; its the RX that's causing issues. 

    Regards,

    Jimit

  • Jimit,

    Do you use 96KHz FS and 24.576MHz bit clock for all McASP (McASP3/4/5)? Can you double check whether you are calculating your bit clock correctly, you ca refer to the below user guide for details how bit clock is calculated:

    www.ti.com/.../sprac09a.pdf

    The most common reasons for RX overrun are described in below document, please have a look:

    www.ti.com/.../sprac10.pdf, 4 Overruns and Underruns (XRUNs)

    Do you get this overrun error occur right after you enable the McASP RX part or McASP starts to receive normally and overrun occur at later stage?

    RX overrun can be also due to system not meeting real-time requirements, check if below doc will be in help for configuring the bandwidth:

    www.ti.com/lit/an/sprac46a/sprac46a.pdf

    Regards,
    Pavel
  • Jimit,

    I was able to find also one difference between McASP3 and McASP4. McASP3_DAT port (0x46000000) is connected to L3_MAIN interconnect, while MCASP4_DAT (0x48436000) is connected to L4_PER2 interconnect. And we have also below notes in AM572x TRM:

    24.6.4.10.1.3 Transfers Through the Data Port (DATA)

    NOTE: McASP1, McASP2, and McASP3, whose data ports are accessible directly via L3_MAIN, do not support FIFO/constant addressing modes. Incrementing transfers must be used instead.

    In a typical McASP transfer scenario, the DMA Controller write accesses the XRBUFn transmit buffer through the McASP data port (DATA) on L3_MAIN Interconect for McASP1/2/3 and on L4_PER2 Interconect for McASP4/5/6/7/8.


    You can check if your SW is aligned with this TRM requirement.

    Regards,
    Pavel
  • Hi Pavel,

    1. I have verified 96KHz FSX and 24.576MHz ACLKX for MCASP3 TX. Since the RX is configured to be in sync with the TX (i.e. MCASP_ACLKXCTL[6] ASYNC = 0), the dividers from  MCASP_ACLKRCTL have no effect and uses the TX's FS and bitclock.
    2. For MCASP4/5, the FS is 16KHz and bit clock is 512KHz (I2S mode with internal clock, ASYNC = 0 )
    3. I am observing overrun right after I enable McASP Rx part and prime the buffers
    4. To account for real-time requirements, I have allocated the transmit and receive buffers on L2SRAM.
    5. If I disable RX, and run only TX, I never see underrun
    6. I have added devmem entries in the custom resource table for the MCASP1/2/3's data port. I just read the section 24.6.4.10.1.3 of TRM.
      1. How should I setup incrementing transfer mode using EDMA LLD in TI-RTOS?

    Regards,

    Jimit

  • I was able to resolve this by changing the rx and tx EDMA hw event number for MCASP3 to CSL_EDMA3_CHA_MCASP5_RX and CSL_EDMA3_CHA_MCASP5_TX instead of CSL_EDMA3_CHA_MCASP2_RX/CSL_EDMA3_CHA_MCASP2_TX. It seems that something else might be using EDMA default hw events for MCASP3 RX. In my application, MCASP6 is unused and so I ended up using it's EDMA hw event numbers. I tried out MCASP2 also and that too required to be remapped to unused MCASP bus.

    I had to make changes to the mcasp_soc.c as well as in the application.

    CSL_xbarDmaConfigure(CSL_XBAR_DMA_CPU_ID_EDMA, 132, 1+CSL_EDMA3_CHA_MCASP5_RX);
    CSL_xbarDmaConfigure(CSL_XBAR_DMA_CPU_ID_EDMA, 133, 1+CSL_EDMA3_CHA_MCASP5_TX);

    Regards,
    Jimit