Other Parts Discussed in Thread: TLV320AIC3101
Hi Champs,
Can I use OBSCLK output as MCLK source for TLV320AIC3101?
I'm planning to use the output as the master clock source for the codec device. So, I'd like to make sure of it.
Regards,
j-breeze
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.
Hi Champs,
Can I use OBSCLK output as MCLK source for TLV320AIC3101?
I'm planning to use the output as the master clock source for the codec device. So, I'd like to make sure of it.
Regards,
j-breeze
Hi j-breeze,
Sure, you could use it, but it may not be reliable for production.
The TRM states that OBSCLK may be used for test and debug purposes only
The Schematic Review Checklist further discourages anyone from using the OBSCLK for... pretty much anything.
See processors.wiki.ti.com/.../_AM1x_Schematic_Review_Checklist
CLKOUT
The CLKOUT clock output is provided as PLL observation clock, and is provided for test and debug purposes only. It should not be used as a synchronous clock for any of the peripheral interfaces because it was not timing closed to any other signals. This clock output also was not designed to source any time critical external circuits that require a low jitter reference clock. The jitter performance is dependent on many system variables, and also influenced by other unpredictable contributors to jitter performance such as application specific noise and cross talk into the clock circuit. There is no characterization data for the jitter performance for CLKOUT.
Can you perhaps use McASP AHCLKX or an external clock oscillator instead?
Hope this helps,
Mark
Hi Mark,
Thank you for your advice.
So, I'm planning to use the McASP AHCLKX output as MCLK source for TLV320AIC3101 and the bit clock ACLKX is input on ACLKX pin. The AHCLKX source is AUXCLK and the codec generates the ACLKX.
And so, could you please let me know whether this case is permitted?
I'd like to make sure of it because it's difference from the "Mixed" case described in the TRM below.
o C6745/C6747 TRM [SPRUH91D SEP16]
(www.ti.com/.../spruh91)
- Page 995
24.0.21 Clock and Frame Sync Generators
・ Mixed - an external high-frequency clock is input to the McASP
on either the AHCLKX or AHCLKR pins, and divided down to produce
the bit rate clock
Regards,
j-breeze
Hi j-breeze,
I think that configuration should work.
You can study the below figures to figure out the mux settings and register bit fields.
I usually trust the audio codec PLL to have less jitter since it is made specifically for sampling audio. The codec usually has a fractional divider to allow you to get all frequencies without a specific crystal that is some multiple of the audio sampling rate.
Hope this helps,
Mark
Hi Mark,
Thank you for your information and I have one more question.
According to a description in the TRM below, I have to feed the ACLKX prior to the McASP initialization.
However, in the case where the McASP AHCLKX output as MCLK source for the codec, I can not do it.
Because the ACLKX is supplied after I set the AHCLKX pin as output in the initialization step 3(d) and the codec generate the bit clock.
Is this procedure OK?
o C6745/C6747 TRM [SPRUH91D SEP16]
(www.ti.com/.../spruh91)
- Page 1006
24.0.21.1.2 Transmit/Receive Section Initialization
... If external clocks are used, they should be present prior to
the following initialization steps.
Regards,
j-breeze
Hi Mark,
Thank you for your reply. I understand.
I've decided to use the McASP1 AHCLKX output as MCLK source for the codec and McASP0 as an audio data port.
So, the codec can get the MCLK from McASP1 and then generate the frame sync and the bit clock for McASP0 before McASP0 initialization.
I think that this method is sure to work. Could you please let me know what you think of it?
Regards,
j-breeze