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.

AM3517 McBSP clk & fs slave questions

Other Parts Discussed in Thread: AM3517, DM3730, AM3703, TPS65930

All,

I'm working on hooking up an AM3517 to 3 separate, but identical, audio chips (voice quality only) using 3 McBSP interfaces. For our implementation, only McBSPs 2, 3, and 4 are available. So, 4-wire interfaces only (no McBSP1).

The audio chip we need to use is a 4-wire interface only, and only supports master mode. It must source both the CLK and FS lines to the McBSP. We assumed this would be fairly trivial since the TRM says the McBSP can be put into slave mode, however we've hit a few snags.

We have our transmit side working decently. Audio is passing, and aside from momentary glitches it sounds pretty good. We're presuming we just have some minor settings to tune, buffers, irqs, etc.

We are getting nothing on the receive path but silence, however. As we have poured back through the TI documentation (sprf98u.pdf), we've found ourselves getting more and more confused. Can you please help us sort this out?

To start with, here are our present register settings. (Please let us know if you need to see something else.)

regs->rcr2 = 0x00000040

regs->xcr2 = 0x00000040

regs->rcr1 = 0x00000040

regs->xcr1 = 0x00000040

regs->srgr2 = 0x0000201f

regs->srgr1 = 0x00000f00

regs->spcr1 = 0x00004030

regs->pcr0 = 0x00000080

regs->xccr = 0x00001009

regs->rccr = 0x00000809

Out of that, the relevant bits for now I think are:

CLKSM=1

SCLKME=1

FSXM=0

FSRM=0

CLKXM=0

CLKRM=0

Section 18.3.2.2.2 (page 1998) says, “Only, the CLKX signal is connected by mcbsp2_clkx pads. The CLKR signal is connected to the CLKX signal. These signals are used like functional clocks by the intermediary of the SRG.” So, that leads me to believe if I get CLKX right, CLKR will follow. However, Figure 18-21 (page 2012) shows “FSR” and “CLKR” as circled in red with a note “McBSP1 only” pointing to them. Figure 18-22 (on the next page, 2013) shows a CLKR for McBSP2, but not how it's attached. And, nothing like that is said about the frame sync pulses.  Here is a more detailed breakdown.

*CLKSM & SCLKME:

We want our clock derived from external McBSPi_CLKX pin for each McBSP. (We cannot use the common CLKS pin since we're looking at multiple, independent audio chips each sourcing their own clock.)

Table 18-25 on page 2053 says to set CLKSM=1 and SCLKME=1 to use the “mcbsp_clkx pin” - which we are assuming is the same as the “mcbspI_clkx” pin. (Is this true?)

*CLKX_int:

Section 18.4.2.3.1 (page 2016) says, CLKXM=0 sets CLKX_int to use mcbspi_clkx as input. (CLKXM=1 would make mcbspi_clkx an output; not possible for us.) CLKX_int = mcbspi_clkx (CLKX) pin. That's what we want.

*FSX_int:

Section 18.4.2.3.3 (page 2018) says, FSXM=0 sets FSX_int to use mcbspi_fsx as input. (CLKXM=1 would make mcbspi_fsx an output; not possible for us.) FSX_int = mcbspi_fsx (FSX) pin. That's what we want.

NOW FOR THE INTERESTING ONES...

*CLKR_int:

Table 18-15 (page 2017) shows that for CLKRM=0 & DLB=0, “CLKR_int is driven by an external clock”.

Which clock??? We have no external receive clock pin on McBSP[2-4], and cannot set CLKRM=1 or that's an output.

*FSR_int:

Section 18.4.2.3.3 (page 2018) says, FSRM=0 means, “FSR_int is generated by an external source and mcbspi_fsr is an input pin” However, McBSP2 does NOT have an mcbspi_fsr pin.

The other option, FSRM=1, means, “FSR_int is generated internally by sample rate generator. The mcbspi_fsx is an output pin except when McBSPi.MCBSPLP_SRGR2_REG[15] GSYNC bit = 0x1”. That's definitely NOT what we want either.

So, how can we simply set FSR_int to use the same frame sync pulse as FSX???

So all we really want is all the frame-syncs coming from the one external frame sync pin,mcbspi_fsx, and all the clocks coming from the one external clock pin, mcbspi_clkx.

Getting there is presently stumping us. Perhaps we're reading too much into the documentation, but at the moment we're stumped as to how to properly set this up.  We are using a current version of Linux.  So, there could be some issues there as well.  However, we know that if we don't get the registers setup right, nothing else will matter.

Thanks!

  • Sorry.  I believe I dropped this in the wrong place.  I'm new to these boards and was having trouble figuring out how to place this in the Sitara area.

    Can it be moved?  Once again, my apologies.

  • A bit more info on this:

    We're still stuck with silence audio on record.  Playback sounds good.  Perhaps these details will help.

    Here is the MUX map we're using at the moment (setup under Linux).

     /* MCBSP2 config */

    OMAP3_MUX(MCBSP2_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),

    OMAP3_MUX(MCBSP2_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),

    OMAP3_MUX(MCBSP2_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),

    OMAP3_MUX(MCBSP2_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),

    We're pretty sure that's all correct.

  • Here is some additional information on the fixed PCM signaling setup of the 'audio device' we are connecting to:

    • Clock master, fixed at 256kHz
    • Frame sync master, fixed 125us frame duration (8kHz): 32 bits of total data; first 16 bits are valid (while FS is high), following 16 are "don't care" (while FS low)
    • 16-bit linear samples, sent MSB first
    • "Long Frame" sync:  transmit and receive occur simultaneously while the common FS line is active (high).
    • TX data with 0-bit delay; start at the rising edge of the clock, while FS is high.
    • RX data with 0-bit delay; sample at the falling edge of the clock, while FS is high.

    Here are our latest McBSP register settings:

    [   34.707092] omap-mcbsp omap-mcbsp.2: DRR2:  0xc4c060
    [   34.712310] omap-mcbsp omap-mcbsp.2: DRR1:  0x0000
    [   34.717315] omap-mcbsp omap-mcbsp.2: DXR2:  0x0000
    [   34.722351] omap-mcbsp omap-mcbsp.2: DXR1:  0x0000
    [   34.727355] omap-mcbsp omap-mcbsp.2: SPCR2: 0x0235
    [   34.732391] omap-mcbsp omap-mcbsp.2: SPCR1: 0x4030
    [   34.737426] omap-mcbsp omap-mcbsp.2: RCR2:  0x0040
    [   34.742431] omap-mcbsp omap-mcbsp.2: RCR1:  0x0040
    [   34.747467] omap-mcbsp omap-mcbsp.2: XCR2:  0x0040
    [   34.752471] omap-mcbsp omap-mcbsp.2: XCR1:  0x0040
    [   34.757507] omap-mcbsp omap-mcbsp.2: SRGR2: 0x001f
    [   34.762512] omap-mcbsp omap-mcbsp.2: SRGR1: 0x0f00
    [   34.767547] omap-mcbsp omap-mcbsp.2: PCR0:  0x0000

    Could someone please check these McBSP settings and let us know if they are in fact correct?

    Thanks.

  • Hi Team,

    Do we have an update available regarding this customer's inquiry?

    Regards,

    Michael

  • Michael, thanks for helping get this to the right place.  Sorry this started off in the wrong forum.

    --------------------------------------------

    By way of an update, we have been able to determine that our clock and frame sync lines are at least being acknowledged by the receiver side of McBSP 2.  We did this by placing a debug printk in the omap-pcm's IRQ.  When both those lines are physically connected and functioning, we see regular interrupts coming up.  When we disconnect either line, no interrupts occur.  We're certainly not ready to say that the clock and frame sync are being perfectly interpreted by the McBSP's receive side, but this would suggest that at least they are being acknowledged properly.

    Through similar printk debugging, we were also able to determine that:

    • ALSA does not appear to be silence filling the data.
    • The SRG of the McBSP is not running, as we would expect it should not be since the McBSP is the slave.
    • The SIDETONE also does not appear to be running, which we likewise are not interested in - we simply want the pure digital data.

    Since the data transfer itself is done by DMA in the Linux kernel, it's been a little tough to actually look at the bits coming up off the wire to see what is there.  We know from the o-scope that non-0 data is being sent over.  It's just being lost somewhere between the wire and userspace.

    One other piece of information to share that may be helpful:  These audio devices we need to hook up to list a few audio codecs that they recommend for use with their digital audio interfaces.  These include:

    • Nuvoton W681360 (http://www.nuvoton.com/NuvotonMOSS/Community/ProductInfo.aspx?tp_GUID=281c7d74-9d3f-4c72-a725-2593c093dc90)
    • Freescale MC145483 (http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MC145483)

    These 2 parts have publicly released datasheets on their respective product pages (see above).  We downloaded these to look at the signaling from their angle, realizing this is in affect what the McBSP must be configured to do.

    Thanks in advance for any help.

  • We are still struggling badly with this.  All debugging efforts so far indicate that what we are receiving in Linux is nothing but 0s on the receive side.  This leads us to believe that we still do not have our McBSP fully configured properly.

    Could someone please take a look at these register settings and let us know if they see something that looks out of place?

    One of key issues we are running into is in our interpretation of the documentation.  Consider the following, taken from page 2061 of the TRM:

    This section does not discuss how one would use a McBSP that does not have a mcbsp_fsr pin.  Since we are using McBSP2 (where the only FSR pin is mcbsp_fsx), and we are not using the SRG (we are slave to everything), how should this be setup?

  • We have shared our Linux driver code on the Linux-omap mailing list:

    http://permalink.gmane.org/gmane.linux.ports.arm.omap/72187

    Hopefully this will provide additional insight for anyone willing to review the issue.

    Thanks in advance.

  • Here's my theory on why your receive data is all zero.

    Your data word size is 16-bits. I assume you DMA word size is also 16-bits? You have SPCR1:RJUST= 0x2 which is left justifying your received data and filling the LSBs with zeros.  So, your data is in bits [31:17] while zeros will be in bits [15:0]. If the DMA is set for 16-bit words then you'll DMA the 16-bits [15:0] filled with zeros to memory.

    Take a look at the "Set the Receive Sign-Extension and Justification Mode" section in theTRM.

      Paul

     

  • Paul,

    THANK YOU SO MUCH FOR TAKING A LOOK AT THIS!  We were certainly running out of ideas, and greatly appreciate your help.

    Regarding DMA size:  That's an excellent theory and one we've not explored.  I will look into it immediately.

    One other small nugget to share that our engineering team verified we have just yesterday is that we're seeing overruns after more than 6 - 10 seconds of recording:

    overrun!!! (at least 80.262 ms long)
    overrun!!! (at least 83.587 ms long)
    overrun!!! (at least 80.688 ms long)
    overrun!!! (at least 206.513 ms long)
    overrun!!! (at least 78.827 ms long)


    I guess we missed this because we tended to not let our tests run more than about 5 secs without anything coming through before we pulled the plug.  We have never seen these on playback.  This may be related to the silence issue, or something else all together.

    Thanks again Paul.  We greatly appreciate it!

  • Paul,

    You are our HERO!  Your hunch was essentially dead-on.

    Our core problem appears to have been a data alignment issue.  In all of our reading of the TRM, we were interpreting the left/right justify setting as strictly relating to the waveform - not considering how that would translate into the received data register.  So, since our waveform was LEFT justified (no padding, MSB immediately available), that's how we set things up.  I considered trying RIGHT justify mode, but only because I thought it wouldn't matter since our signal required no padding in the waveform.  In the end, we obviously never did.  With no padding, I surmised it could be either without affect.  All along, however, I was obviously missing the fact that this would be captured into a 32-bit register, and that register could/would do some adjusting of its own based on these settings.

    I never actually confirmed in code whether the DMA is configured for 16-bit or 32-bit transfers, though I do believe it is doing 16s.  Regardless, your suspicion that the wrong bits were being masked and kept was obviously correct.  Simply changing our alignment to RIGHT justified mode and leaving the data in the low-order word allowed us to instantly get what we needed.

    Thanks again for your review and help.  It was more than greatly appreciated.

  • Hi,

    We are doing something similar to you on a DM3730 which seems to have an identical McBSP register setup. Would it be possible for you to share your final register setup as this would go a long way to helping us setup the McBSP in slave mode. My guess is the registers will be setup as follows:

    MCBSPLP_RCR2_REG -    Receive control register 2 (0x40 - 16bit)
    MCBSPLP_RCR1_REG -    Receive control register 1 (0x40 - 16bit)
    MCBSPLP_XCR2_REG -    Transmit control register 2 (0x40 - 16bit)
    MCBSPLP_XCR1_REG -    Transmit control register 1 (0x40 - 16bit)
    MCBSPLP_SPCR1_REG -    Serial port control register 1 (0x30 - RJUST=0, RINTM=3)
    MCBSPLP_SRGR2_REG -    Sample Rate Generator register 2 (0x201f - FPER=32, CLKSM=1, Input CLK<-CLKX)
    MCBSPLP_SRGR1_REG -    Sample Rate Generator register 1 (0xf00 - FWID=16)
    MCBSPLP_PCR_REG -    Pin control register (0x80 - SCLKME=1, Input CLK<-CLKX)
    MCBSPLP_XCCR_REG - Transmit configuration control register (0x1009 - DXENDLY=1, XDMAEN=1, XDISABLE=1)
    MCBSPLP_RCCR_REG - Receive configuration control register (0x809 - RFULL_CYCLE=1, RDMAEN=1, RDISABLE=1)

    Thanks,

    John

  • John

    Do you see an issue with your configuration?

    What data format with the McBSP be receiving, # of words, word size (16-bit), TDM or I2S, etc?

      Paul

  • john3909 said:

    We are doing something similar to you on a DM3730 which seems to have an identical McBSP register setup. Would it be possible for you to share your final register setup as this would go a long way to helping us setup the McBSP in slave mode.

    Hi John,

    Like PaulM, I'm not sure what your audio data format looks like, so I'm not sure how similar our confgs really are.  Our final settings ended up basically being what we had posted above.  I believe the only thing that changed for us, based on PaulM's suggestion, was we moved from left justified to right justified.

  • Hi all,

    I need to clarify one doubt.

    I have used MCBSP2 for interfacing AM3703 with TPS65930 through I2S interface.

    So I have got MCBSP1,3,4 & 5.

    I need to interface HDMI TV to AM3703. So I need additional audio output from AM3703.

    My HDMI transmitter IC supports I2S audio input.

    Question 1: So is this ok to use MCBSP5 for another I2S interface from AM3703 to HDMI transmitter IC.But the problem is "Application field - MIDI Data" in MCBSP5 interface

    Question 2: Moreover what is the use of audio buffer exclusively used in MCBSP2. Will that makes the audio frequency support higher?

    Question 3: The absence of audio buffer in MCBSP5 will reduce the audio frequency support?

    Question 4: Is this possible to make use of MCBSP1 for this audio interface.

    Thanks

    Karthik