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.

CC2564MODN: Problems sinking audio using STM32

Part Number: CC2564MODN
Other Parts Discussed in Thread: CC2564

Hello,

I'm new to the world of BT, so I appologize if my question is basic.

Using the CC2564MODNEM board, and the examples on the TI website to connect to STM32F4.

I did all STM32F4 porting needed to the code (as described in "Bluetopia STM32F4xx Porting overview")

I run the SPPDemo. All ok.

Now trying to run the A3DPDemo.

The CC2564MODNEM board is connected to the SM32F4 Discovery board via UART only.

The Audio/PCM from the CC2564MODNEM board  is connected to a coded (I believe this is called assisted A2DP).

Running the A3DPDemo Project on the STM32, pairing to an Android device succeeds, and music the was playing on the Android device now goes "mute".

"SendPassThroughCommands" with pause/stop, works just great. The player on the Android device pauses/plays.

The problem is - no signal is active on the RF2/P11 (AUD_FSYNC_IN), therefore - no signal at the codec and no sound from the speakers...  :-(

What is wrong?

  • Lino,

    Are you using the STM3240G-EVAL board as you host EVM? If not, please refer to the following note from SDK User's Guide.

    Best regards,

    Vihang

  • Yes, indeed I'm using STM32F4DISCOVERY board.

    Why shouldn the A3DPDemo_SNK not work on this board? The STM32F4DISCOVERY board is connected to CC2564MODNEM via UART only, the PCM/I2S goes directly from CC2564MODNEM to a codec (I've disconnected the codec, because I want to see some signals on FSYNC first).

    Thanks

  • Hello all TI Experts,

    I'm going to rephrase my problem:

    I'm trying to stream audio from an Android device (the source) via Bluetooth to CC2564MODNEM (the sink).

    CC2564MODNEM is controlled by an STM32F4DISCOVERY board. Porting to STM32 has been done as described in TI's "Enable STM32 Discovery Eval" (and worked great with the SPPDemo).

    My set up looks like this:

    (At a later stage CC2564MODNEM will be connected to a codec and speakers)

    Running the A3DPDemo_SNK project from "CC256x STM32 Bluetopia SDK v4.0.2.2" results in a successful pairing the the Android device.

    Playing audio on the Android phone doesn't make a sound from the phone's speakers - which gives me the impression the audio is sent via Bluetooth to the CC2564MODNEM.

    Using a lab oscilloscope I can see there is no signals coming out of the CC256MODNEM on the PCM/I2S lines (FSYNC,AUD_IN,AUD_OUT, AUD_CLK).

    What signals should I excpect to see?  (I imagine at least a clock on FSYNC)

    What am I doing wrong?

    Any extra code needs changing in the A3DPDemo_SNK demo?

    Below is the log from the terminal:

    OpenStack().
    Blutooth Stack ID: 1

    Device chipset: 4.1
    BTPS Version: 4.0.2.1
    Project Type: 6
    FW Version: 7.26
    App Name: A3DPDemo_SNK
    App Version: 0.1
    BD_ADDR: 0xCC78....xxx...

    Mute and enter the DAC, CS43L22, into power save mode with reset

    A3DP Endpoint opened successfully

    Class of device: 0x040424

    Supported formats:
    Frequency: 44100, Channles: 2, Flags: 0
    Frequency: 48000, Channles: 2, Flags: 0
    Frequency: 48000, Channles: 1, Flags: 0
    Frequency: 44100, Channles: 1, Flags: 0

    ***************

    commands...

    **************

    A3DP+SNK>

    atlOCapabilityResponse: 0x....

    Capabilities: Display Yes/No, MITM

    A3DP+SNK>

    atlOCapabilityRequest: 0x....

    Auth success

    A3DP+SNK>

    atlOConfirmationRequest: 0x....

    Auto accepting: %

    GAP_Authenication_response success.

    A3DP+SNK>Un-handled Auth. Event.

    A3DP+SNK>

    atLinkKeyCreation: 0x...

    Link Key Stored.

    A3DP+SNK>

    etAUD_Signalling_Channel_Open_Indication

    BD_ADDR: 0x....

    A3DP+SNK>

    etAUD_Stream_Open_Indication

    BD_ADDR:    0x...

    MediaMTU:   672

    StreamType: SNK

    A3DP Open: 0

    Send HCI Flow Spec for guarenteed ACL connection

    Send HCI VS DDIP for ACL priority over scans

    Initialize audio with sample Freq: 44100

    I2S configuration start f: 44100

    !!! Error in startDAC() !!!

    A3DP+SNK>

    etAUD_Remote_Control_Open_Indication

    BD_ADDR: 0x...

    A3DP+SNK>

    etAUD_Stream_State_Change_Indication

    BD_ADDR: 0x...

    StreamType: SNK

    StreamState: Started

    A3DP Start: 0

    A3DP+SNK>

  • Help still needed.
    If anyone out there can assist - will be highly appriciated.

    Thank you!
  • Help still needed.
    If anyone out there can assist - will be highly appriciated.
  • I think the OP might be able to reference this post for help with the startDAC error (e.g. discovery board does not have an IOExpander and the code needs to change accordingly to use I2C directly)

    But , are you able to expand on the exact details why the STM32F4DISCOVERY board is unable to *playback* audio for these demos? Of course SW needs to change, and resistors modified (R11 removed), but the note specifically calls out "hardware limitations". The only noticeable differences in components or connections on the Audio schematics are that the eval board has an IO expander (shouldn't be the problem) but also has a frequency synthesizer on the I2C SDA/SCL lines on the same CS43L22 codec.

    Every post I've read so far, as well as what I'm seeing, indicates issues on the I2S lines from the CC2564 eval board (and the adapter board) that causes issues hearing any sound from HP/LINE_OUT on CN4 (with or without powered headphones/speakers)

    Thanks,

    Joe

  • Adding others who've posted over the years about Audio and the Discovery board. Thanks ahead of time.

    , , ,  )

  • Joe Nasti said:
    But , are you able to expand on the exact details why the STM32F4DISCOVERY board is unable to *playback* audio for these demos? Of course SW needs to change, and resistors modified (R11 removed), but the note specifically calls out "hardware limitations".

    These limitations include the audio codec IC(s) used on the discovery board and the lack of proper connections to interface it/them with the CC256x. The discovery board is not a TI EVM, so the exact root cause of all of these issues on this EVM is not known to us.

    These limitations are a non-issue when designing your own system or wiring a different audio codec to the board. But then, the relevant HW and SW changes need to be worked out in that case. Not ideal to get a demo working as a first step.

    In any case, it is best to start with a working setup: the EVAL board mentioned in the user's guide. All the sample applications work out of box on the supported hardware. So once you have a working setup, you can start porting to your application/system needs.

    Best regards,

    Vihang