• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 101 subscribers
  • Views 220 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.

AM4378: McASP works and the connections

Kanae
Mastermind 9745 points
Part Number: AM4378
Other Parts Discussed in Thread: TLV320AIC3104,

Hi Support Team,

My customer has the following question regarding McASP for AM437x processors.

We are checking the operation on a prototype board, and we believe that there is a problem
with the way McASP works and the connections that were assumed when the board was created.
The connection relationship between the CPU (AM4378) and CODEC (TLV320AIC3104) that
was originally planned is as follows.

-Supply MCLK from CPU to COEDC
-CODEC operates in master mode
-Supplies BCLK and WCLK divided in CODEC to CPU
-Output audio data from CPU to CODEC
-DA audio in CODEC is played back through speakers via AFAMP

Reference diagram: originally planned connection


My understanding was insufficient at the time of design, but I have rechecked
the AM437x Technical Reference Manual "24.3.5 Clock and Frame Sync Generators"
and the Application Report SPRACK0, and have the following confirmation/questions.

Please answer the following questions.

Q1. Are each of the following recognitions correct?

-To output data from the CPU to the CODEC, routing to the internal data transmission XCLK and internal frame sync is required.

-CLK input from outside to the MCASP0_ACLKR and MCASP0_FSR pins can be routed to RCLK and internal frame sync for reception.
 The XCLK and Internal frame sync cannot be routed to the XCLK and Internal frame sync for transmission, and thus cannot be used in the expected manner.

-For example, if BCLK and WCLK from CODEC were connected to MCASP0_ACLKX and MCASP0_FSX pins,
 they could be used in the configuration originally envisioned.

-Since MCASP0_ACLKX and MCASP0_FSX are capable of routing not only to transmit but also to receive RCLK
 and internal frame sync, BCLK and WCLK can be routed to MCASP0_ACLKX and MCASP0_FSX regardless of the data transmission
 or reception, master mode or slave mode configuration. ACLKX and MCASP0_FSX could be used as long as they were connected.


Q2. If we want to support this without modifying the board, is it possible to use the following configuration?

The signal input/output relationship should be as follows: CPU as master, CODEC as slave mode,
and the routing of the McASP clock inside the CPU should be as follows.

In the block diagram of Transmit and Receive, it is assumed that the frequency divider ratio of Divider is aligned.
AUXCLK is shown in red for transmit and blue for receive in the figure below,
but it is assumed to be synchronized if the source is the same.

Transmit Clock Generator Block Diagram


Receive Clock Generator Block Diagram


Frame Sync Generator Block Diagram

Please excuse this configuration, which is not usually used.
However, we need to consider whether it is possible to handle this without modification of the board.

Immediate support for the above question would be greatly appreciated.
I would like to have your prompt reply, or a schedule of this reply at least.

Best regards,
Kanae

  • +1
    TI__Mastermind 29440 points

    Hi Kanae,

    Q1
    Yes, unfortunately the transmitter logic inside McASP transmits using clocks from ACLKX and AFSX pins instead of ACLKR and AFSR pins which you have connected.
    Yes, in sync mode (MCASP_ACLKXCTL. ASYNC = 0) both transitter and receiver logic share the ACLKX and AFSX pins. In this mode, I believe ACLKR and AFSR pins are not active/ they are ignored.

    Q2
    Your proposal to use ACLKR and AFSR as outputs to the codec might work.
    The generated clock on ACLKR pin should match the generated clock on ACLKX pin if they use the same divider settings from the same AUXCLK source. Datasheet timings are not guaranteed for transmitter data to the receiver clock ACLKR, but there is probably loads of margin with this AIC3104.
    My concern is if AFSR will remain synchronized with the signal on AFSX. You may need to service Receiver and Transmitter interrupts simultaneously and start both simultaneously.

    Do you have access to the AFSX signal on this board? I recommend proving that AFSR and AFSX remain synchronized by probing AFSX and AFSR. If you have access to ACKLX also, I would check it against ACLKR to ensure the are in-phase
    If you do not have these signals on your board, then recommend find a board that brings these signals out from the processor, like the EVM.

    =-=-=-=
    On another topic, you should verify that your system can achieve desired audio sampling rates.
    In the first case where codec generates BCLK and FS, can the AHCLKX pin provide an appropriate clock frequency to the codec MCLK that is necessary to achieve typical audio sampling rates like 48kHz or 96kHz. The codec should have a fractional divider used to get very close to these target frequencies. For example if AUXCLK = 26MHz and you divide this by 2 (13MHz) and give to the codec MCLK, the PLL multiplier and fractional divider inside codec needs to multiply by 1625 and divide by 6 to achieve 48kHz exactly.

    The 26MHz in this example is the maximum master oscillator crystal which is tapped for auxclk
    Refer to Figure 6-24. ADC0, ADC1, DCAN, and McASP Clock Selection and Table 24-3. McASP Clock Signals in AM437x TRM.

    In the second case where AM437x generates BCLK and FS, there are only integer dividers available to generate audio clocks. This often forces the choice of crystal oscillator.
    Consider these possible crystal frequencies for the master oscillator:
    19.2MHz / 400 = 48KHz - perfect, possible (AHCLK = AUXCLK div 4 , ACLK = AHCLK div 16)
    24MHz / 500 = 48KHz - perfect, possible (div 4, div 25)
    25MHz / 520 = 48.076KHz - not perfect, possible (div 20, div 26)
    26MHz/ 540 = 48.148KHz -  not perfect, possible (div 18, div 30)
    Muliple different divider combinations are possible.
    HCLKRDIV/HCLKXDIV ranges from div-by-1 to div-by-4096
    CLKXDIV/CLKRDIV ranges from div-by-1 to div-by-32

    Let me know if you have more questions.

    Regards,
    Mark

  • 0 in reply to Mark M
    Mastermind 9745 points

    Hi Mark,

    Thank you for your detailed answers.
    I will share this with my customer and check with him
    if he has any additional questions.

    Best regards for your continued support.

    Kanae