• State
  • Locked Locked
  • Replies 13 replies
  • Subscribers 101 subscribers
  • Views 1449 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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 clocking problem with external clock on C6747 EVM - McASP0 OK but McASP1 not working with same settings/code

Arvid Tomayko-Peters
Intellectual 640 points

Hi, I'm working on a project where we are interfacing the 6747 EVM board with a custom board that has 8 codecs transmitting and receiving using I2S. They are connecting to McASPs 0 and 1 on the C6747. Everything is clocked from our custom board, the frame sync and bit-clock of which are connected to AFSX and ACLKX of both McASP0 and 1.

We need to use both McASPs because we need 8 serializers in and 8 out, and also plan to use the EMIF and ethernet - which together take up about half the pins on each McASP.

Anyway, the problem is that I can get audio I/O perfectly fine on McASP0, but on McASP1, with the same clock connection and exact same register configuration (except for different pin I/O in PDIR), I get lots of pops and clicks (maybe 10/second/channel, even when input should be close to silence), bad audio and a stoppage of SIO buffer reclaiming after 1-10 seconds. The code for McASP 1 is exactly the same as that for McASP 0 (just pass audio - based on ...\pspdrivers_01_30_00_05\packages\ti\pspiom\examples\evm6747\mcaspDit with modifications), as are the configurations. I've also tried code that just runs the McASP 1 segment of the application, with the same ugly results, and code the splits the two McASPs into separate TSK threads - in which case the McASP0 thread runs and clocks fine, and the McASP1 thread dies after 1-10 sec of noisy popping.

I was thinking maybe I'd damaged McASP1 with a static discharge or something, but the audio example project in PSP using the internal codec to pass audio onMcASP1 works flawlessly. I also tried adding 33-Ohm resistors to the clock lines to stop possible reflections - no change.

So...

1. I've come to the conclusion that there must be some hardware issue - is there anything different design-wise between McASP1 and McASP0 on the C6747 that could be causing this? Any ideas about why this might be happening?

2. Or maybe that it is interference from the onboard codec of the EVM board, which is maybe not completely disconnected by pulling MUX pin 2 high and is trying also to send a clock signal to McASP1? So I was trying to find example code to configure the onboard codec - but could not short of using the whole audio driver. Is there a sample project or code anywhere that just shows how to initialize and configure the AIC31 codec on the C6747 EVM board?

Thanks in advance!

  • 0
    TI__Guru 62975 points

    Arvid,

    The BSL test code for the C6747 EVM has some basic configuration code for the AIC3106 chip.

    How fast are you operating the McASP clocks/data?  Are you using EDMA to service the data?  If so, is the EDMA Queue/TC for McASP1 being used for other tasks?

    This information may help some: http://processors.wiki.ti.com/index.php/OMAP-L1x/C674x/AM1x_Multichannel_Audio_Serial_Port_%28McASP%29_Throughput_and_Optimization_Techniques

    -Tommy

  • 0 in reply to tlee
    Intellectual 640 points

    Thanks - I actually just found the BSL code and am going to try integrating it. It does not seem to use the AIC31 driver in the PSP, but that is fine for now.

    The clocks are a Left/Right clock at 48kHz for audio, and a bit clock at 32x that frequency - 1.536MHz. They look fine on a scope - although I don't have enough experience to say how much noise I should see in a clock like that, but it looked very reasonable.

    I am using the McASP driver from the PSP install which uses the EDMA behind the scenes to move data in and out of SIO stream buffers that I issue and reclaim from a TSK task thread in (for now) an infinite loop - the project is based on the mcaspDITSample project in ...../pspiom/examples/ebm6747/mcaspDIT except modified for both in and out and changed to use TDM instead.

    Right now the EDMA is doing nothing but servicing the McASP (either one or both depending on which test code i am running) via the McASP driver (that is I assume it is doing nothing else - since I'm using the pre-built driver). I'm using that so I can avoid having to deal with the EDMA at a low level - but I will try that if I must - I just figured the driver would be robust and easier.

    Also - this clock/codec system used to work OK with a C6418 EVM board that we recently abandoned because of the extra features and lower cost of the 6747. On that we were also using 2 McASPs (as well as a McBSP) to do audio I/O, but doing things at a lower level.

    Another thing is that I get the same awful audio and them dying thread when running only a generated sine wave out on McASP1 with no audio input, as in the original mcaspDITSample example project that I based this code on.

  • 0 in reply to Arvid Tomayko-Peters
    TI__Mastermind 29141 points

    I don't think this is an issue with the board.  Looking through the schematics some (not all) of the McASP1 pins can be routed to either the on-board codec or to the expansion connector.  You cannot route them to both at the same time.  The transmit frame sync (AFSX1), transmit high-frequency clock (AHCLKX1), and transmit bit clock (ACLKX1) are some pins that can go to the codec.  If you are using any of these pins in your daughtercard, then the issuse is likely not at the board level (without these pins you would hear zero audio).  As long as you have EXP1_SEL_MCASP1 pulled up on your daughtercard, the on-board codec should be totally out of the loop.

    Some McASP1 pins are also muxed with an eQEP expansion connector, but unless you have something connecting to P12 on your board and that something is pulling SEL_EXP2_QEP1 low, that should not be an issue either.

    The symptoms of the problem sound more like software issues.  I would focus on that.

     

     

  • 0 in reply to Gus Martinez
    Intellectual 640 points

    thanks. EXP1_SEL_MCASP1 is definitely high - i tested with a meter. My question was just if maybe the switch it controls was not quite up to the task of completely blocking out the clock from the codec - though that would, I agree, be a very slim chance given that this EVM board was definitely built by capable engineers.

    It's just weird that the same exact code and register settings work for McASP0 and not McASP1. Even when all either McASP is doing is using 1 serializer to send 2 channels of sine wave out, with no inputs. So I'm trying to find some difference between the two McASPs that I can latch onto and maybe figure out why I get different results with them, besides that maybe I killed one with ESD (although the audio driver example with internal codec as master and McASP 1 as slave works fine - so probably not).

    Also, I've tried using my code with both the C6747 and the OMAP configurations of the EVM with the same results.

  • 0
    TI__Mastermind 29141 points

    Arvid Tomayko-Peters said:
    The code for McASP 1 is exactly the same as that for McASP 0 (just pass audio - based on ...\pspdrivers_01_30_00_05\packages\ti\pspiom\examples\evm6747\mcaspDit with modifications), as are the configurations.

    Are you disabling DIT mode in this example?  Only McASP2 supports DIT mode on C6747.

  • 0 in reply to Gus Martinez
    Intellectual 640 points

    Yes - I am using TDM. ditctl is 0x00000000, the McASP registers are set for 2-slot TDM, I2S format. I have tried both using and not using the 'package' struct to send buffers, and the mcasp channel config struct is set for TDM - excuse me if I'm getting names of these wrong - the code is not available to me to look at right now. Is there anything else that might be required to use TDM instead of DIT mode?

    I am definitely getting my desired signal through for a few seconds, but with lots of pops and it dies a few seconds after starting when using McASP1.

  • 0 in reply to Arvid Tomayko-Peters
    Expert 2790 points

    Hi ,

    In DM6467, I want to use McASP port 0 for transmit data and port 1 to generate high frequency clock (AHCLKX) (to be used as master clock for another audio DAC in the system.) Is there any limitation to use both ports simultaneously?Pls reply

    Regards

    JK

  • 0 in reply to Jayakrishnan
    TI__Guru 62975 points

    JK,

    The DM6467 has a different architecture from C6747.  Please start a new thread in the DM64x forum: http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99.aspx

    -Tommy

  • 0 in reply to Arvid Tomayko-Peters
    Intellectual 355 points

    Arvid,

    Did you ever find a resolution?  I am having similar issues, but my audio lasts anywhere from several minutes to hours.  I am using MCASP1 also.

  • 0 in reply to Eric Hereford
    Intellectual 640 points

    Hi Eric,

    No - no resolution. We just built a new codec daughterboard and switched to using three 6in/8out codecs instead of 8 stereo ones so we could get all our channels on McASP0's serializers.

  • 0 in reply to Arvid Tomayko-Peters
    Expert 1080 points

    Arvid,

    I am using McASP0 for input (I need 15 inputs) and McASP1 for output ( I need 8 outputs).  I do not have my own board at the moment but I am using the Spectrum Digital L137 EVM with the 4 channel audio board.  The audio board works on McASP0 only but I modified the audio board to get the audio data and clocks to both McASP0 and McASP1.  My master clock is the A/D converter and it feeds both the bit and word clocks to the McASP0 and McASP1.  AS the McASP0 is for inputs the AFR1 and ACLKR1 are used and and as the McASP1 is for the outputs AFSX1 and ACLKX1 is used.   I am using i2s mode.  My code is based on PSP 1.30.01.  I have not seen any issues with clicks or pops.   I do have a post on the BIOS forum about setting up multiple McASPs with PSP 1.30.01 that you may want to look at but if you have code running then you probably figured out what to fix in the PSP. 

    Regards,

    Fawad

  • 0 in reply to Fawad Nackvi62335
    Intellectual 640 points

    thanks Fawad. I think I found your post - http://e2e.ti.com/support/embedded/f/355/t/83628.aspx ? - and I'll take a look at it for future reference. For now we are OK because we only need one McASP since we're using multichannel codecs - they are cheaper anyway in the long run if you're doing 18+ audio ins and outs.

  • 0 in reply to Arvid Tomayko-Peters
    Expert 1080 points

    Arvid,

    This post of mine is better

    http://e2e.ti.com/support/embedded/f/355/t/91371.aspx

    I am glad you fixed your problem by going to a codec with TDM mode I assume. Good lateral thinking.  But I wish TI would have been able to help you solve the issue. As it would have helped me too :)

    Regards.

    Fawad