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.

Usung I2C with CC8530 and TLV320AIC3204

Other Parts Discussed in Thread: CC8530, TLV320AIC3204

Hello,

I am begining a project with the CC8530 and AIC3204. I would like to keep the I2C data path between these chips but i need to send some more data to the AIC3204 and the only way is the SPI connected to the cc8530.

With the PurePath Configurator it is easy to send the initial configuration to the AIC3204. But my working configuration is in host mode. My controler has a SPI connection and i need to send some more controls to the AIC3204.

How can i send data through the CC8530 to the TLV320AIC3204.

Thank you for your help

Bernard

  • Hi Bernard,

    If you want to control the aic3204 from the CC85xx you cannot use SPI for this. CC85xx is an SPI slave only. You could in theory have the CC85xx controlling something via the I2C, and have the MCU controlling something else via SPI. But I see that the I2C pins for aic3204 are used in the SPI interface as well (SDA and MOSI are the same pins, and SCL and SPI_chip_select is the same pin). Then the CC85xx will sense disturbance on the I2C interface, and it will be reset, so this will not work. If you are not able to do what you want entirely from the CC85xx your only option is to control all aspects of the aic3204 from the MCU, and disconnect the I2C interface between the CC85xx and the aic3204. If SPI is the only way of controlling the functionality you want you will have to have two different chip select signals i.e. one for the CC85xx (you mentioned you are running in host contolled mode) and one for the aic3204.

    But why is the only way SPI? What are you trying to do? I would guess that I2C works fine? Simply modify the I2C sequences in the configurator to update the registers you want.

    -Kristoffer

  • Hi Kristoffer

    Thank you for this answer and it seems that my first idea is not applicable.

    This is the first structure

    With this structure I initialize the CC8530 and the AIC3204 using the stream given by the PurePathConfigurator and i use the CC Debugger. After that the only orders I can send through SPI are those described in the CC8530 User’s guide (SWRU2501 September 2011) in table 26 page 95 in host mode column.

    In this case the SPI link doesn’t allow me to work on the internal register of the AIC3204.

    The possibility that seems ideal should be to add some new commands for instance to generate beeps. I don’t know if this is possible.

    The other configuration I can do is this one :

    In this structure, the MCU can address either the CC8530 or the AIC3204.

    That will change the initial configuration generated by the PurePathConfigurator because it will not be able to initialize to the AIC3204 with the CC Debugger.

    I believe that the MCU will have to send the different configurations sequences to the AIC3204. After that it will be easy to do what I want with this chip.

    Can you confirm which structure is the best for me.

    Thank You

    Bernard

  • Hi Kristoffer,

    In my last post, the schemes are not accepted. So i can explain them.

    The first one use the structure shown in the Pure Path SDK. The AIC3204 is connected to the CC8530 with an I2C link and the SPI of the CC8530 is connected to the MCU. The MCU is SPI master and has 1 slave.

    In the second structure, the MCU is connected to the CC8530 with a SPI link using a chip select and connected with the AIC3204 with the same SPI link using another chip select. The MCU is SPI master and has 2 slaves.

    Best regards

    Bernard

  • Hi Bernard,

    It is correct that the SPI commands (known as the EHIF interface) described in the user guide don't handle anything with the codec. This is only for controlling CC85xx functionality. However it's possible to control the power state of the CC85xx via EHIF with the PM_SET_STATE command, and this will in turn make the CC85xx send its pre-configured I2C sequences to the codec (see more info on this further down in the post). It's important to understand that the CC Debugger doesn't communicate with the codec. It only programs the CC85xx with I2C sequences which will be given to the codec during operation when the power state is changed.

    You mention that you will generate beeps. Is this supposed to happen upon a button press etc? This will not be possible with todays firmware. I2C commands is only issued to the audio device in the transition between states. We considered to develop something like this (issue an I2C sequence to the codec upon a button press), but decided not to, and instead wait for demands from the field. It would be very helpful if you explained what exactly you want to control in the aic3204.

    In the todays configurator you can enable custom setup of the codec. You do this in the Audio Interface panel. Then a new panel will appear in the project tree i.e. the "Audio device customization" panel. Go into this panel and click the "Reset all button". You will now see the I2C sequences that will be executed by the CC85xx during the different state changes. This you can modify as much as you want to fit your needs. If this is not sufficient you could do what you refer to as structure 2, and have the MCU control everything (both the CC85xx as well as the aic3204).

    Hope this clarifies things.

    -Kristoffer

  • Hi Kristoffer,

    Your answer confirms exactly what I was afraid of. That is to say : there is no possibility to create a link between the AIC3204 and the external MCU through the CC8530 using the SPI connected to the CC8530.

    If this project as I don’t have a long time for my design, I believe I will have to use my second structure with 2 SPI slaves instead of one.

    What I wanted to do was to use the internal generator of the AIC3204 to generate beep to the HP output to give some informations to the listener. I have seen in the SLAA446 that it was possible. Furtherly I would also be able to change dynamically the DRC or the AGC according to the earing conditions.

    Thank you

    Best regards

  • Hi Bernard, 

    Your input on this is really interesting and we are constantly looking at how we can improve our offering. 
    We are thinking about how to increase support for the capabilities of devices like the AIC3204 and have some ideas on our drawing block, but we're not ready to get into details on how and when this will be a part of the offering though. 

    Regards,
    Kjetil