Random occurence of XDMAERR with my McASP and EDMA configuration

Hi Phan,

Do you use DM816x device? Do you use DM816x TI EVM or custom board? Do you use EZSDK 5.05.02.00? From what I understand you are running audio application on your board and there you have these issues.


Regards,
Pavel

See also if the below wiki pages will be in help:

processors.wiki.ti.com/.../McASP_Tips
processors.wiki.ti.com/.../TI81XX_PSP_AUDIO_Driver_User_Guide
processors.wiki.ti.com/.../Linux_Core_Audio_User's_Guide
processors.wiki.ti.com/.../TI81XX_PSP_04.04.00.02_Feature_Performance_Guide

processors.wiki.ti.com/.../TI81XX_PSP_EDMA_Driver_User_Guide

Regards,
Pavel

Hi Pavel,

Yes I'm using DM816x on a custom board for audio application and I don't use EZSDK.  I have two mcasp/edma channels configured for two audio bus running at a different clock speed.

Regards,

Phan

QH Phan said:

and I don't use EZSDK

What you are using than? Is it TI software?

Regards,
Pavel

I'm using CCS 5.3.0.00090 with the following packages

Regards,

Phan

Phan,

OK, you are using SYS/BIOS.

The XDMAERR (transmit DMA error) occur when the DMA (or CPU) writes more words to the DAT (data) port of the McASP than it should. An occurrence indicates a serious loss of synchronization between the McASP and the DMA or CPU. You should reinitialize both the McASP transmitter and the DMA to resynchronize them.

Refer to DM816x TRM, section 14.2.8.4.4 DMA Error - Transmitter

Regards,
Pavel

Hi Pavel,

i'm a colleague of Phan who is also looking into this issue and am currently investigating the clock configuration of the processor. I was wondering if there were factors that would increase the chances of loss of synchronization between the McASP and DMA ?
Are some system clock domains ratios to one another sensitive to causing desynchronization ? (i.e. ratio between multiplier/dividers used to generate SYSCLK4 (DMA source) and SYSCLK19 (McASP Transport) )
are there any impacts on synchronization between using internal or external clock source on the McASP ?

Vincent

Hi Vincent,

You might hit errata Advisory 2.1.107 McASP to EDMA Synchronization Level Event can be Lost

See DM816x Silicon Errata document.

Regards,
Pavel

Hi Pavel

With regards to the advisory, I noticed that we do not use the hardware FIFO in our implementation and was wondering if we should observe the XDMAERR issues with the McASP without using the FIFO thresholds discussed in the errata (RNUMEVT and WNUMEVT registers are not used).

Otherwise, I have attempted to modify our configuration in order to use an internal clock source instead of an external clock source and am experiencing some issues. Here is our initial configuration where XDMAERR will occasionally be reported..

• Initial McASP configuration (external source, occasional XDMAERR)
o MCA0_AHCLKX and MCA0_AHCLKX receive 4.092MHz clock from external source.
o MCA0_ACLKX is configured to 512KHz, MCA0_AFSX is configured to 8KHz
 4 timeslots x 16 bit, timeslots 0-3 active
o MCA1_ACLKX is configured to 4.092MHz, MCA0_AFSX is configured to 8KHz
 16 timeslots x 32 bit, timeslots 0-15 active


I started by replacing the external clock source with an internal source of the same rate, this configuration worked however as the sampling clock of the codec was tied to the external source some clicks and pops could be detected in the audio output. I did not exercise this configuration enough to capture data about the occurrence of the XDMAERR.

• Intermediate McASP configuration (codec sampling issue)
o SYSCLK20 used as clock source for the McASP, configured for 4.096MHz
o MCA0_ACLKX is configured to 512KHz, MCA0_AFSX is configured to 8KHz
 4 timeslots x 16 bit, timeslots 0-3 active
o MCA1_ACLKX is configured to 4.092MHz, MCA0_AFSX is configured to 8KHz
 16 timeslots x 32 bit, timeslots 0-15 active
modifications : sysclk configuration, AHCLKXCTL.HCLKXM , AHCLKRCTL.HCLKRM

The following step involved reconfiguration of the codec sampling clock source. This modification required the bit clock of the McASP port to be increased to a minimum of 1MHz in order for the clock to be in acceptable range to be used by the codec PLL to generate the 8KHz sampling clock. As the documentation indicated that the serializers are only active during the active timeslots i have not modified the application servicing the DMA and am writing the same amount of data to the DMA buffer. However when starting the DSP with this configuration I experience frequent and periodic XDMAERR errors. I have measured the ACLKX AND AFSX signals of both interfaces in the different configurations and confirmed that the configured clock rates are correct.
I am wondering if I missed something in the configuration modifications I did or if the XDMAERR is becoming more frequent because of the modifications to the clock rate of the McASP ?

• Modified McASP configuration (internal source, frequent XDMAERR)
o SYSCLK20 used as clock source to the McASP, configured for 4.096MHz
o MCA0_ACLKX is configured to 1.024KHz, MCA0_AFSX is configured to 8KHz
 8 timeslots x 16 bit, timeslots 0-3 active, 4-7 inactive
o MCA1_ACLKX is configured to 4.092MHz, MCA0_AFSX is configured to 8KHz
 16 timeslots x 32 bit, timeslots 0-15 active
modifications to McASP0 : ACLKXCTL.CLKXDIV (divider changed from 8 to 4), AFSXCTL.XMOD , AFSRCTL.RMOD (number of TS increased from 4 to 8). note : synchronous transmit and receive.
RTDM and XTDM were unchanged (TS0 to TS4 active)

From what i have observed, the configuration appears to work for a small period of time (300-500ms) before the XDMAERR error occurs.

I am still investigating the issue but any pointers you can provide would be appreciated. I can provide initial and modified configuration if desired.

Vincent