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

OMAP4: I2S over McBSP audio issue

Alex Portnov
Prodigy 40 points

Hello,
In our project we use OMAP4460 SoC running 4AJ.2.2 software release.

Connected to it is external audio module sending in PCM data over I2S  (into OMAP, one direction only).
Connected to McBSP2 (signals verified by scope, looks fine), attached into ABE instead of BT-VX-UL (in ABE data path).

The problem is that we're not able to capture any at CPU side. Recorded file is all zeroes, beside wav header - no errors on run/init.

So I guess there's something wrong with my clock configuration? Some other parameter?
Below are the settings I'm using.

Can anyone point me into right direction? What wrong/missing here?

Thanks in advance.


3 pads:
External module generates all the signals (clock, frame sync and data)

abe_mcbsp2_clkx - 1024kHz
abe_mcbsp2_fsx  - 16kHz
abe_mcbsp2_dr   - 32bit per sample, per channel PCM data, 2 channels

// configured as
OMAP4_MUX(ABE_MCBSP2_CLKX, OMAP_PIN_INPUT | OMAP_MUX_MODE0),
OMAP4_MUX(ABE_MCBSP2_DR, OMAP_PIN_INPUT_PULLDOWN | OMAP_PIN_OFF_OUTPUT_LOW | OMAP_MUX_MODE0),
OMAP4_MUX(ABE_MCBSP2_FSX, OMAP_PIN_INPUT_PULLDOWN | OMAP_PIN_OFF_INPUT_PULLDOWN | OMAP_MUX_MODE0),


sdp4430.c
sdp4430_mcbsp_hw_params()
...
    ret = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBM_CFM);
    ret = snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_SYSCLK_CLKS_FCLK,1024000, SND_SOC_CLOCK_IN);

    ret = snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_SYSCLK_CLKR_EXT,1024000, SND_SOC_CLOCK_IN);
...


mcbsp_be_hw_params_fixup()
...
    snd_mask_set(&params->masks[SNDRV_PCM_HW_PARAM_FORMAT - SNDRV_PCM_HW_PARAM_FIRST_MASK], SNDRV_PCM_FORMAT_S32_LE);
...

static struct snd_soc_dai_link sdp4430_dai[] = {
    {
        .name = OMAP_ABE_BE_BT_VX_UL,
        .stream_name = "BT Capture",
        .cpu_dai_name = "omap-mcbsp-dai.1", // changed here
        .platform_name = "aess",
        .codec_dai_name = "Bluetooth",
        .no_pcm = 1,
        .no_codec = 1,
        .be_hw_params_fixup = mcbsp_be_hw_params_fixup,
        .ops = &sdp4430_mcbsp_ops,
        .be_id = OMAP_ABE_DAI_BT_VX,
        .ignore_suspend = 1,
    },
...

omap-abe.c
enable_be_port(...)
...
case OMAP_ABE_DAI_BT_VX:
        ...
            format.f = 16000;
            format.samp_format = STEREO_MSB;
            abe_connect_serial_port(BT_VX_UL_PORT, &format, MCBSP2_RX);
            omap_abe_port_enable(abe_priv->abe, abe_priv->port[OMAP_ABE_BE_PORT_BT_VX_UL]);
        ...

# ABE routing BT-VX-UL to MM-UL2
tinymix 22 120      # BT UL Volume
tinymix 44 7        # MUX_UL10 to BT Left
tinymix 45 8        # MUX_UL11 to BT Right
tinycap /sdcard/test.wav -d 1 -b 32 -c 2 -r 48000


[  167.877105] **** McBSP2 regs ****
[ 1223.254150] DRR2:  0xb7c5986
[ 1223.257507] DRR1:  0x0000
[ 1223.260681] DXR2:  0x0000
[ 1223.263763] DXR1:  0x0000
[ 1223.266815] SPCR2: 0x0230
[ 1223.269866] SPCR1: 0x0031
[ 1223.272918] RCR2:  0x80a1
[ 1223.275970] RCR1:  0x00a0
[ 1223.279022] XCR2:  0x80a1
[ 1223.282073] XCR1:  0x00a0
[ 1223.285125] SRGR2: 0x003f
[ 1223.288330] SRGR1: 0x1f00
[ 1223.291381] PCR0:  0x008f
[  167.921295] ***********************


  • 0
    Prodigy 170 points
    Hello Alex,

    I'm currently trying very similar exercise and here is the link for it
    http://e2e.ti.com/support/omap/f/849/p/388865/1384706#1384706

    Only differences being, i'm using the Ubuntu 3.4 kernel and tapping the signals from the MCBSP1 port which is default the BT port on the board. Looks like i'm in the same state as you are in .

    Whats the current status ? Was there any updates ? Pls do share your findings ...

    Thanks,
  • 0
    TI__Mastermind 29520 points

    Hello Alex,


    Had you checked your PRCM configuration.

    I assume that your MCBSP2 module might be not functional if you do not enable the MCBSP power and clock domains.

    Check following registers and set them with the correct values:

    PM_ABE_PWRSTCTRL[1:0] POWERSTATE - Power state control 0x3: ON State
    CM1_ABE_CLKSTCTRL[1:0] CLKTRCTRL - Controls the clock state transition of the ABE clock domain. - 0x2: SW_WKUP: Start a software forced wake-up
    transition on the domain.
    CM1_ABE_AESS_CLKCTRL[1:0] MODULEMODE - 0x2 Module is explicitly enabled.
    CM1_ABE_MCBSP2_CLKCTRL[1:0] MODULEMODE - 0x2: Module is explicitly enabled.

    Check register - CM_ABE_PLL_REF_CLKSEL

    Best regards,

    Yanko












     

  • 0 in reply to Yanko Todorov-XID
    Prodigy 40 points

    Thank you Yanko!

    I did check the registers you mentioned, CM1_ABE_CLKSTCTRL value was wrong -  something to do with sleep mode?

    It also caused me to check all the McBSP values, bit by bit.

    It turns out the linux driver (omap-mcbsp.c) names clock master and slave reverse, in addition to not implementing slave mode clocks properly.

    Problem solved.

    @: It indeed looks similar.

    From my experience - if DRR2 stays always constant, you have no data coming in (McBSP issue); otherwise its ABE routing issue.

    There are 3 clocks needed  - data clock, frame clock and internal. If one of them not configured properly, you wont get anything. Each one can have different source.

    The best advice I can give you is checking all reg values manually vs OMAP TRM document - the linux drivers are minimal at best.

    If your goal is to get the SCO packets from BT  (basically 8/16kHz 16bit PCM data quantized) - you have different way doing it :) You can configure TB chip to send SCO data via HCI and not PCM, then just open SCO socket at CPU and rcv the data. This is dependent on your Bluetooth chip, but if you use any TI's, it is supported.

    Best regards, Alex.