• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 216 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.

TDA4AP-Q1: McASP RX clock generation

Bogdan Lazic
Prodigy 20 points
Part Number: TDA4AP-Q1


Tool/software:

Hi,

I am working on a custom board based on the TDA4 chip, aiming to enable the McASP interface in I2S mode. The TDA4 should generate both clocks on the MCASP0_ACLKR and MCASP0_AFSR pins. The TDA4 only receives audio data, so only the RX side is active and connected.

Linux davinci-mcasp driver defaults to synchronous mode (SYNC) when operating in I2S mode.

When the CFG_ACLKXCTL[ASYNC] bit is set to 0 (Synchronous mode), the FS clock is not routed through the RX pin. However, if the bit is set to 1 (Asynchronous mode), without making any other changes, the clock output works as expected.

Could you please confirm whether this is the expected behavior? Specifically:

  • In synchronous mode, are both TX and RX clocks (MCASP0_ACLKX and MCASP0_AFSX) generated exclusively, with the MCASP0_ACLKR and MCASP0_AFSR pins remaining unused?
  • Are there any other limitations, beyond the driver implementation, that would prevent the McASP interface from operating in asynchronous mode when only the receiver side is active?

Best regards,
Bogdan

  • +1
    TI__Mastermind 20590 points

    Hi Bogdan,

    Bogdan Lazic said:

    Could you please confirm whether this is the expected behavior? Specifically:

    • In synchronous mode, are both TX and RX clocks (MCASP0_ACLKX and MCASP0_AFSX) generated exclusively, with the MCASP0_ACLKR and MCASP0_AFSR pins remaining unused?

    The TRM states: "Optionally, a receiver can use ACLKX as the serial clock when a transmitter and receiver (not from the same serializer) of the MCASP are configured to operate synchronously."

    The register description states: "0 Synchronous. Transmit clock and frame sync provides the source for both the transmit and receive sections."

    From this, It appears if the McASP is set as synchronous, the receive clock and frame sync aren't active. So the behavior is expected. The clocks do come from the same source however, so it would make sense for them to be the same if the McASP is set to asynchronous and the transmit and receive dividers are equal.

    Bogdan Lazic said:
    Are there any other limitations, beyond the driver implementation, that would prevent the McASP interface from operating in asynchronous mode when only the receiver side is active?

    No, there should not be.

    Can you read through this document and see if it answers any of your other questions: https://www.ti.com/lit/an/sprack0/sprack0.pdf 

    Best,
    Jared

  • 0 in reply to Jared McArthur
    Prodigy 20 points

    Hi Jared,

    Thank you for prompt and precise response, it is really helpful.

    Best regards,
    Bogdan

  • 0 in reply to Bogdan Lazic
    TI__Mastermind 20590 points

    Hi Bogdan,

    I assume this thread is resolved, and am closing it.

    Best,
    Jared