CC3200 I2s in slave mode

Hello TI, old thread, but remains relevant. Please update with your information on I2S slave. I have learned directly from that TI that this is possible and that the Slave setting works. Please update this thread TI with an answer!

Hi Ciaran,

Are you referring to your I2S thread? e2e.ti.com/.../508495

Best regards,
Sarah

Hi Sarah,

No. In the thread you mention I describe how I used the SPI peripheral to work as a slave I2S - it's a workaround and not a terribly nice solution. Since then I have obtained information from TI which says the I2S peripheral on the CC3200 can in fact be used in slave mode.

Ti should post that information here with sample code. Please.
Ciarán

Hi,

Where you get information that I2S slave mode is supported? In SWRU367C is described this:

The CC3200 hosts a multi-channel audio serial port (MCASP). In this version of the device, only the Inter-
Integrated Sound (I2S) bit stream format is supported. Given the nature of integration of this peripheral on
the CC3200 platform, developers should use peripheral library APIs to control and operate the I2S block.
These APIs are tested to ensure I2S operation in master mode (CC3200 sources the I2S bit clock and
frame synchronization signals), while interfacing with external audio codecs.

Jan

Hi Jan,

I got the information from my support contact in TI, who was kind enough to chase it up with the APPs team and they did some tests and confirmed that slave mode works. I would really like to see TI post that information here, or otherwise make it public. The more users the mode gets exposed to the better chance potential problems might be identified. I have not used the mode in production code yet and am currently still trialling it.


Ciarán

Hi Jan,
You can see my code posted on my new link at
e2e.ti.com/.../570823

which unfortunately outlines some unexplained behaviour of the I2S peripheral.

The code I have posted is entirely my own and not officially recommended by TI. If you need code that is officially approved by TI please contact TI yourself.
Ciarán

Hi Ciarán,

I have a similar problem - on board there is a 3G modem, which supports PCM Master only. I learned
with code you kindly provide. But there is nothing any ability to try your driver so long as it is unclear how the functions
i2s_rx/tx_start() are called and where did the interfaces 'hal.h' & others come from?
Could you be so kind as to comment this slightly?
Thanks in good time.

Hi Vlad,
It's quite simple actually - rx_start just takes a rcv buffer and starts the peripheral. The only tricky bit is the word sync. I know my modem drives data to me in the left channel with the right channel blank. So when receive starts I configure the Frame Sync pin as gpio and check it. I know that if the current ISR interrupt has fired (byte received) and the frame sync is low, then I'm synced so from now on I just use a toggle to pick up every alternate word, that is to say, the right channel is dropped. So bytes from both channels are causing interrupts but only one of the channels is used.

tx_start is similar but takes a tx buffer. sync is simpler, but experimenting I know which frame sync word is tx first by the peripheral, so I use a toggle to write one of my audio words in every second interrupt. For the blank channel I just write word = 0.

hal, audio, debug and trace are headers from my own modules. Audio is just to allow me to call into my audio layer to give/take more data. The hal is 'hw adaption' layer and is merely a tool to toggle leds install/enable interrupts in nvic.

I hope this helps,
Ciarán

Hi Ciarán,
Usually by analogy "hw abstraction level' (hal) stands over drivers' level in system and serves for standartization calls and for
optimization of drivers' buffering and embodies interfaces for low-level calls of functions.
Information about NVIC contained in the TRMl is clearly not enough to write functions hal_nvic_int_enable/disable/register ().
Maybe you know of other sources and you could share them?
Thanks in advance.

Practicially all my low-level code that is specific to the CC3200 came in one form or another from the examples in the SDK. I have no other sources I'm afraid.

Regarding hal - yes true, point taken. But my system is, in the end, a relatively simple one and I have used a thin wrapper layer on configuration of system clocks, enabling interrupts etc.

By the way the documentation is not good - there is too much information missing on certain peripherals and TI refer us back to their SDK library. But that is surely not a good enough response - most experienced embedded designers at this level would expect good detail on peripherals etc.
Ciarán

Hi Ciarán,
It is quite clear that code in volume you posted, does not help anyone. And those who analyze it, simply lose time and receive sanctions
from their employers. So, decide and post all the code - let it be tried by the whole community. There is nothing to worry about - for the
unofficial code provided "as is" no liability occurs, and TI will benefit from public testing of software.

Now the whole community is looking at you - make a decision.
Br,
Vlad

Hi Vlad,

I feel no obligation to post any more code -- my original post was merely to illustrate a way of word syncing the audio stream given the limitations of the peripheral. Configuration of clocks and interrupts is amply illustrated in the SDK examples. If you need further assistance I suggest you contact TI directly.

All the best,

Ciarán