• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 101 subscribers
  • Views 483 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

McASP & EDMA, loosing samples

Dzmitry Balashenka
Prodigy 60 points

Hello,

We use a custom board based on DSP TMS320DM642AGNZ (A5, 2003, CC-28C5FFW) and we have an issue in production - around 10-30% of boards do not pass audio quality test. After investigation we discovered that samples are dropped occasionally at a rate around 1-3 samples per 10000 inside of the DSP. For those boards which pass the test the problem is never reproducible.

We have checked signals integrity and everything seems o.k. The DSP temperature has no effect.

We found a workaround which seems to be working, but we need your help to understand what is happening. And eventually we have to decide weather we should allow these cards in production.

In our configuration we use McASP to communicate with two codecs AIC23. In further tests we will be using digital loopback at DSP level, so codecs are not required to reproduce the issue.

McASP configuration:
- external clock 12.288MHz is taken from AHCLKX0
- ACLKR0, AHCLKR0,AMUTE,AMUTEIN are not used and not connected
- AFSR0, AFSX0 pins are connected together on the board.
- Master mode, Frame Sync and BCLK are generated by DSP
- TDM mode, 32KHz frame rate, 3072MHz BCLK, 6 time slots from which only 2 are active
- 16 bit sample size

EDMA configuration:
- Four channels are configured to serve two serializers: EDMA_CHA_AXEVTO0, EDMA_CHA_AXEVTE0, EDMA_CHA_AREVTO0, EDMA_CHA_AREVTE0.
- Linking is used to alternate two (ping-pong) buffers for each channel.
- Buffers are located in internal SRAM.
- The interrupt is set for each 512 samples.

We found several case which makes the issue disappear:
- TDM mode, FS 32kHz, 1024MHz BCLK (instead of 3072MHz), 2 time slots
or
- Using internal clock instead of external AHCLKX0 (external signal quality has been certified by our expert). 
or
- TDM mode, FS 32KHz, 3072MHz BCLK, 6 time slots. But mark active 3 timeslots on TX side (instead of 2).

To help investigate the issue I stripped the production code to make a minimal test application, which you can find in the attachment. It does not depend on any external hardware (except for external clock 12.288MHz on AHCLKX0 pin).

Software tools description
- Code Composer version 3.1.23
- Code Generation Tools 5.1.10

Thank you

Best regards,
Dzmitry

mcast-test.zip
  • 0
    TI__Mastermind 35645 points

    Hi,

    Thanks for your post.

    Let me take this forward to hardware expert to investigate this issue and consult on the same to provide you the cause of this issue.

    Please give us some time to analyse and provide suggestion on the same.

    Thanks for your understanding.

    Regards,

    Sivaraj K

  • 0
    TI__Mastermind 35645 points

    Hi Dimitry,

    Thanks for your post.

    I guess, the audio samples are dropping occasionally on 10-30% production boards which should be because of timing mismatch in the synchronization of the external clock operating speed on AHCLKX0 pin and only so, the issue is happening randomly which is not consistent in all boards. So, in my opinion, the external clock operating speed mismatches the timing synchronization and there cause the mess-up which is happening intermittently on few non-working boards. This could be the reason, the audio samples are dropping only occasionally and not consistently at a rate of 1-3 samples/1000.

    This is basically a external clock synchronization issue which is why, if you use internal clock instead of external clock sourced from AHCLKX0, you are not experiencing the audio sample drop issue even occasionally too. 

    If you need more investigation, i would recommend you to post this request to DM64x forum to be better answered.

    Thanks & regards,

    Sivaraj K

    -----------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question

    -------------------------------------------------------------------------------------------------------

  • 0 in reply to Sivaraj Kuppuraj
    Prodigy 60 points

    Hi Sivaraj,

    Thank you for your answer. I reposted the question in DM64x forum as you suggested.

    I do not think that this is clock synchronization issue. I assume that McASP was designed to operate with external clock and this is normal. We also made a number of verifications to be confident in the quality of the external clock.

    When talking about clock synchronization we usually refer to two clock domains. I am not sure which second clock you keep in mind. In our case we have EDMA and McASP using with different clocks, but this is normal condition.

    Thanks again,

    Best Regards,
    Dzmitry

  • 0 in reply to Dzmitry Balashenka
    TI__Mastermind 35645 points

    Hi,

    Thanks for your update.

    Let me close this thread in this forum line since you have re-posted the query to the appropriate forum.

    Thanks for your understanding.

    Regards,

    Sivaraj K