• State Resolved
  • Locked Locked
  • Replies 19 replies
  • Answers 5 answers
  • Subscribers 16 subscribers
  • Views 868 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC8520: I2C Master Control of Audio Codec

Arthur Thompson27
Expert 1725 points
Part Number: CC8520
Other Parts Discussed in Thread: TLV320ADC3101, , CC8531

Hi,

I am trying to add a feature to my design that allows an external microphone to become the audio source when it's plugged in, and an internal microphone will be the audio source otherwise.

The way I want to implement this is to wire each microphone to a different input on my audio codec (TLV320ADC3101).  Then when some detection circuit identifies the external mic has been plugged in, an I2C command would be sent to the codec to program the registers to switch the input source.

I currently have the codec under control of the CC8520 (I2C Master), so the ADC3101 is just sent some "State Configuration Sequences" to turn it on.  I don't know how the CC8520 could command it to switch from "ON, Mic input A" to "ON, Mic input B".

The CC8520 is in EHIF mode under control of a microprocessor.  Is my only option to make the TLV320ADC3101 a slave of the microprocessor?  Or does the CC8520 have some way to do this?

Thanks,

Arthur

  • 0
    Expert 1725 points
    I'm wondering if since I'm not using the volume control, I could hack the .ppwadd file to make it so "Volume Up" sets the input to Mic A and "Volume Down" sets the input to Mic B.
  • 0 in reply to Arthur Thompson27
    TI__Guru 58425 points
    Hi Arthur,

    I will look into this as get back to you. In mean while, could you fill in with the role of your CC8520 in the system (is it acting as slave or master)?
  • 0 in reply to IUsedToBeARealPerson (M-W)
    Expert 1725 points

    Hello,

    This CC8520 is a Protocol Slave.

    Thanks,

    Arthur

  • 0 in reply to Arthur Thompson27
    TI__Guru 58425 points
    Hi Arthur,

    There is no support for implementing this on the CC8520 side, unfortunately you can not "hack" the volume signals to achieve what you want.
    In theory, it might be possible to get something working but it would be unofficial and something I can't support you in here in the forum, you are however free to PM me and I can explain more.
  • 0 in reply to IUsedToBeARealPerson (M-W)
    Expert 1725 points

    Hello M-W,

    Thank you for the answer.  Since we will likely need to move the control of the codec off of the CC8520 and onto our CPU, can you provide some guidance as to what the CPU needs to do to control the codec?

    I think I'm just looking for you to confirm that all we need to do is send the same initialization sequence to the codec.  I just want you to confirm we DON'T have to do something like muting the Slave ADC's output when the CC85xx reports enough packet loss that some audio samples had to be muted.

    Is there anything special we need to do to coordinate the timing between the setup of the codec and when the CC85xx starts clocking the I2S bus?

    Thanks,

    Arthur

  • 0 in reply to Arthur Thompson27
    TI__Guru 58425 points
    Hi Arthur,

    It is hard to say what you would need to do exactly if you went with the "Two masters" approach. At the very least you would need to make sure that the configuration done by the CC8520 is not overriding the configuration you do with the main CPU. In PurePath configurator, you can choose to edit the I2C configuration for the different states, I would in this case advice you to "remove" any of the audio sink/source settings done by the CC8520 and instead do this on your main CPU.

    The same reasoning goes for the "mute" feature, you would need to look over which settings the CC8520 can do and which you would need to control as a consequence of this.

    As for timing, I would recommend you make sure that the codec is setup prior to engaging any I2S activity.
  • 0 in reply to IUsedToBeARealPerson (M-W)
    Expert 1725 points

    M-W,

    My plan is to totally disconnect the audio codec's I2C interface from the CC85xx, (unless you're telling me I should do otherwise and use a multi-master approach).  The audio codec's I2C will only be connected to my CPU.

    How do I make sure the codec is set up before engaging I2S activity?  I don't see how I have any control of whether the CC85xx is driving the audio clocks.  When does it begin driving them and is there a EHIF command I can use to pause it while we're setting up the codec over I2C?

    Thanks,

    Arthur

  • 0 in reply to Arthur Thompson27
    TI__Guru 58425 points
    Hi Arthur,

    I have looked into it and it seems that there is no way to explicitly control the audio clocks from host side.

    An option that might be a solution for you is to configure the CC8531 control sequences to toggle an IO and then delay (up to 1-2 seconds) before proceeding. You can then catch this IO as an interrupt on your device and configure the codec during the delay period of the CC85XX device.

    You would need to setup your own Audio Device Definition File to add the desired IO pin to the confiscator. Then you need to enable "custom setup" for the audio device and fill these in as described in the GUI (there is notes on how to toggle IOs and delay the device).
  • 0 in reply to IUsedToBeARealPerson (M-W)
    Expert 1725 points

    M-W,

    Is it correct that the CC85xx doesn't drive the I2S clocks until the Configuration Sequence under "Audio Device Customization" has completed?  So you're saying we just have to delay that sequence until our I2C configuration is complete?

    Thanks,

    Arthur

  • 0 in reply to Arthur Thompson27
    TI__Guru 58425 points
    Hi Arthur,

    I believe the answers to your questions might be in the User's Guide, chapter 3.5.3.1:

    "Some audio device register operations may depend on a reliably running audio clock. The CC85xx’s internal
    audio clock source will (when used):
    * Never run during transitions between the OFF and SR-SWITCH states
    * Always run during transitions between the SR-SWITCH, INACTIVE, LOW-POWER and ACTIVE
    states
    "
  • 0 in reply to IUsedToBeARealPerson (M-W)
    Expert 1725 points
    M-W,

    Please let me review a strategy with you and see if I understand

    1) Our CPU tells the CC85xx to go to SR-SWITCH mode. Now the CC85xx is sourcing clocks to the Codec, but the CC85xx isn't trying to transmit audio.
    2) Our CPU sends the I2C configuration sequence to the codec.
    3) Our CPU tells the CC85xx to switch to ACTIVE mode. Now we're ready to send valid audio over the air.

    With this flow, there is no GPIO signalling required, the CPU just gets to decide when it's ready to move the CC85xx to the next state.

    How do we move between the states in section 3.5.3 via EHIF commands?

    Thanks,
    Arthur
  • 0 in reply to IUsedToBeARealPerson (M-W)
    Expert 1725 points
    I had to ask a follow up question so had to mark this post as "not resolved"
  • 0 in reply to Arthur Thompson27
    TI__Guru 58425 points
    Hi Arthur,

    As far as I know, there is no EHIF command to force these modes, these are simply internal states the device move between depending on other factors.
  • 0 in reply to IUsedToBeARealPerson (M-W)
    Expert 1725 points
    M-W,

    Is OFF to SR-SWITCH the only sequence for which we should have the CC85xx use a GPIO to signal to the CPU that it's time to configure the audio codec?

    Thanks,
    Arthur
  • 0 in reply to Arthur Thompson27
    TI__Guru 58425 points
    Hi Arthur,

    I believe this should be enough, if you force the device in and out of low-power mode when you need to perform the switch it should be enough.
  • 0 in reply to IUsedToBeARealPerson (M-W)
    Expert 1725 points

    Hello M-W,

    Can you define for me how the CC8520 exercises its Audio device reset control pin?  I'm seeing it reset not only when the board first boots up, but also when the slave connects to the Master's network.  I'm seeing glitchy behavior.  We have I2C control of the codec wired to the CPU, but the codec reset line is wired to a Audio device reset control GIO on the CC8520.

    Thanks,

    Arthur

  • 0 in reply to Arthur Thompson27
    TI__Guru 58425 points

    Hi Arthur,

    The reset pin is controlled by the configuration script so you should be able to see how this is exercised by looking over the configuration sequences you use. In the "Audio Device Customization", press the "Set all seq. to default" button to load the default configuration defined for the CODEC, you should be able to identify the pin here.

  • 0 in reply to IUsedToBeARealPerson (M-W)
    Expert 1725 points

    I don't understand why the pin resets when the Slave connects to a network.  What "States" are we transitioning through when the device goes from disconnected to joining a network?  Most of my states have no sequence except OFF to SR-SWITCH and SR-SWITCH to OFF

  • 0 in reply to Arthur Thompson27
    TI__Guru 58425 points

    Hi Arthur,

    As you say, reset should only toggle during the OFF to SR-SWITCH and SR-SWITCH to OFF states. I tested this myself running the DK example and I do not see the reset pin toggling during connections but only during an actual device reset. On your hardware, is the reset pin connected to something else as well that could impact it?