• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 1682 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.

PROCESSOR-SDK-AM335X: McASP asynchronous input and output

Wiebe Cazemier
Prodigy 70 points
Part Number: PROCESSOR-SDK-AM335X
Other Parts Discussed in Thread: DIR9001, PCM1690

Hi,

In this thread, it's recommended to use two McASP ports when using two codecs. But, the datasheet says:

The McASP consists of transmit and receive sections that may operate synchronized, or completely independently with separate master clocks, bit clocks, and frame syncs, and using different transmit modes with different bit-stream formats. The McASP module also includes serializers that can be individually enabled to either transmit or receive.

And:

The receiver also has the option to operate synchronously from the ACLKX and AFSX signals. This is achieved when the ASYNC bit in the transmit clock control register (ACLKXCTL) is cleared to 0 (see Figure 22-18). The receiver may be configured with different polarity (CLKRP) and frame sync data delay options from those options of the transmitter.

But then there is the davinci-mcasp kernel driver that states that all serializers need to have the same amount of TDM slots.

I already have a board that connects everything to mcasp0, so I hope I don't have to redo it. Any insight welcome.

  • 0
    Prodigy 70 points
    With some IRC'ing, I think I figured it out. The hardware can do it, but Alsa-SOC is designed to have 'a codec' on an interface, and there is only one clocking mode.

    Time to start hacking with wires.
  • 0
    Prodigy 70 points

    Part Number: PROCESSOR-SDK-AM335X

    Hello,

    I'm working on connecting a optical digital audio receiver (DIR9001, for TOSLINK/COAX) to the multi-channel audio serial port (McASP) on the Beagle Bone Black. Whereas a PCM1690 DAC that I also connected works, the signals going into the input pins of the CPU have the problem that they suffer from voltage drop and high current draw.

    When I manually set my reset-active-low line to high as a GPIO, everything works fine. When I input an optical signal, I can trace L/R clock, bit clock and data on my scope. Then, when I load my kernel driver, which uses the Davinci system I guess, the peak voltage of the square wave bus signals drops from 3.3 V to about 1.1 V. Plus, the 22 Ohm serial resistor in the bus line measures 0.5V peak over it, meaning there is about 20 mA of current draw. It's as if the McASP pins I use for input suddenly get a very low resistance.
    I use P9 pin 12, 27 and 30 (mcasp0_aclkr, mcasp0_fsr and mcasp_axr0) and they all exhibit this behavior. The control modes are 0x2E, 0x28 and 0x28. In other words, the input buffer is enabled. I tried having pull up/down enabled and disabled.
    My McASP DTS overlay is:
        fragment@2 {
            target = <&mcasp0>;
            __overlay__ {
              pinctrl-names = "default";
              pinctrl-0 = <&mcasp0_pins>;
              status = "okay";
              op-mode = <0>;          /* MCASP_IIS_MODE */
              tdm-slots = <8>;
              serial-dir = <  /* 0: INACTIVE, 1: TX, 2: RX */
                2 0 1 0 /* The McASP has four serializers/channels. I use axr0 as input from DIR9001, and axr2 as output to PCM1690 */
              >;
              tx-num-evt = <1>; //enble tx_fifo (boolean)
              rx-num-evt = <1>; //enble tx_fifo (boolean)
           };
        };
     
    Does anybody have an idea why this voltage sag and/or current draw happens?
  • 0
    Prodigy 70 points
    Basically, the answer is the same as this: e2e.ti.com/.../2205722

    The entire port can only have one Alsa clocking mode, so my input pins are configured as output.
  • 0 in reply to Wiebe Cazemier
    TI__Guru**** 393215 points
    Those are Linux limitations, not hardware. Thanks for the update.