PDA

View Full Version : XMC4500 I2S questions



mhelin
Jan 25th, 2013, 08:16 AM
It hasn't been written anywhere what is the actual maximum data word leght for the I2S (which is oddly called IIS in reference manual). I installed DAVE and noticed that it supports maximum of 16-bit words, is this the maximum for the device too? The XMC4500 reference manual tells though:

"17.6.1.2 Protocol Overview
An IIS connection supports transfers for two different data frames via the same data line,
e.g. a data frames for the left audio channel and a data frame for the right audio channel.
The word address signal WA is used to distinguish between the different data frames.
Each data frame can consist of several data words."

Please tell me what that last sentence "Each data frame can consist of several data words" means in practice, does it mean that the I2S support is not actually limited to 16-bits but several words can be transmitted to FIFO (/DMA) during single frame transfer when the WA (which should really be called LRCK in the manual) is for an instance kept low for usual 32 sample clocks (SCLK is the correct abbreviation for this signal used these day; Philips/NXP though used SCK, and WS for LRCK and SD for sample data which is SDIN or SDOUT) for the left I2S frame? So if I set the SCTR.FLE to 32 and SCTR.WLE do I get two words transferred via I2S output meaning mamimum of 32 bits of data / frame (64 total) could be transferred. I'm sorry but the reference manual is quite confusing to say. Then how about the DAVE 3, there isn't place for setting the FLE, should it be manuallu configured, or should it allow I2S word lenghts of lets say 24 (in 32-bit frame) which is stadard today (there aren't many 16-bit devices available anymore) and DAVE should the generate code which sets the WLE and FLE and other relevand bits correctly.

Ok, please clarify. Also what is the best way to ensure that sor an example one input channel and eight output channels are started and working synchronously so that the left I2S channel will be always the first frame and words in the beginnign of the DMA buffer?

ron
Feb 14th, 2013, 12:20 AM
In USIC IIS mode the number of data bits transferred after a change of signal WA is defined by SCTR.FLE(bit[21..16], max. 63 bits). A data frame can consist of several data words with a data word length defined by SCTR.WLE(max. 16 bits). The changes of signal WA define the system word length as the number of SCLK cycles between two changes of WA. The number N of SCLK cycles per system word length is defined via BRG.PCTQ and DCTQ (N = (PCTQ + 1) (DCTQ + 1)).
The current DAVE version has restriction in IIS configuration settings, for example, 1. FLE == system word length and two channels are used for sample frequency calculation; 2. only one output pin is configured as alternate output for WA (SELOx).
For DAVE setting with FLE=31 and WLE=15 that means the first 2 words (2 x 16bits_word, muss use TxFIFO or DMA so that no delay between the first and second word transmission) is transmitted while WA=low.
For your application the output pins (max. 4 available in XMC4500) for SELOx must be added in DAVE code.

SharmanJ
Aug 15th, 2013, 09:20 PM
Hi
I'm new to DAVE and XMC4500 (Relax Kit), so please be tolerant. I am finding the above two comments confusing. I would like to do a really straight forward IIS DAVE set-up if possible - one that connects the Relax Kit to a stereo 24-bit ADC using IIS either in Slave or Master mode. [I'm using the ADC in a mono mode.]
I figured from how DAVE is configuring IIS that it wants the XMC4500 to be the master. If I go that route I have to configure and wire an MCLK to the (slave) ADC - possibly problem 1 - I'm finding it difficult to see how to do this, but I may be forced by DAVE and Relax pin-out restrictions to do so. If I make the XMC4500 a slave to the ADC, I need an external clock source (could be XMC4500 or an xtal oscillator), and unless I'm wrong, DAVE can't set up this mode (XMC4500 is Slave) - there are some reasons why I would like to go this route, one being I have already ordered components and a PCB. [I have logged/ticketed a documentation issue on the Relax Kit re IIS Slave mode.]
But, the biggest issue is interpreting the DAVE settings in terms of the XMC4500 reference manual - the terms are different, and the pop-up help is next to useless, hence my confusion.
The obvious worry is: can I or can I not transfer 24bit data from the ADC (mono is ok, master or slave), and if so, how do I achieve this (examples using both DAVE and register settings). According to the DAVE help pages IIS is only mono, so does it discard say the right channel? How?

Jackson
Aug 19th, 2013, 02:16 AM
Hi SharmanJ,

I find it hard to disgest your problem here.
Perhaps because i'm not really familiar with IIS protocol.
However, if you could list down your problem/issue one by one, it would be easy for me to understand and assist you.
From what I understood, you wanted the IIS to be slave. This is not possible with DAVE Apps as the app is develop for Master mode.
For slave, you can initialize the channel itself.
Please refers to this forum page, we have user share with working code for IIS slave.
http://www.infineonforums.com/threads/829-I2S-on-XMC-Relax-Lite-Kit

SharmanJ
Oct 30th, 2013, 08:01 PM
Hi Jackson
Since commenting on this thread, DAVE 3.1.8 was released and I'm now working with that; it has an I2S002 DAVE App. I have just started work in the IIS part of the project - using the Wolfson WM8737 ADC with AGC. This device has a write-only SPI port for setting it up, and can be placed in a variety of data output modes - for this project I'm using IIS and I was planning to use the XMC4500 in slave mode and ADC in master mode, together with an external XTAL oscillator.

I have briefly looked at the thread and it may be of use, but I was trying to avoid hand crafting too much of the XMC4500 code.

I2S002 supports only XMC4500 in master mode which means the MCLK must come from the processor, not the oscillator - this is because the sample rate (i.e. WA frequency) is tied to the ADC input clock by a divider in the ADC. Thus:
If XMC4500 is master: MCLK must be an exact multiple of the WA frequency (in my app 750 x WA, I'm having to use 16-bit values as a limitation of the I2C002, but I would rather handle 32-bit ADC values, so the SCLK frequency is also tied to MCLK and WA). The problem is: how do I set up the MCLK so it produces a 12MHz clock for the ADC, and that this clock is used for generating the SCLK and WA signals?
If XMC4500 is slave: External oscillator is an exact multiple of the WA and the data clock, but as the ADC is in control, there are no problems... Except I would like to use 32-bit data and so this means the FIFO queue cannot be used - one cannot set it into a 32-bit data mode. So it's bit bashing the data or use 16-bit, and hand craft the slave mode. Note: the oscillator frequency in this mode has been chosen to be 12.288MHz and this requires a divide by 768 - the reason for this choice is a better low-pass filter characteristic - the WM8737 has a built-in anti-aliasing filter.

This leads me on to a question - why, if the XMC4500 supports IIS, there are limitations built in to the hardware (USIC) that all but prevents 32-bit use? I'm looking forward to your next processor family that is truly 32-bit capable. [Audio processing requires a lot of processing power, and this should not be squandered on packing up 16-bit words into 32-bit words, or bit bashing a port.]

SharmanJ
Nov 5th, 2013, 09:48 PM
Hi Jackson
I have looked into the code supplied above (http://www.infineonforums.com/threads/829-I2S-on-XMC-Relax-Lite-Kit) and it is not compatible with XMC4500 - some defines are not in the XMC4500.h file. This causes me some problems as I would have liked to understand more what is happening.
I would like to understand a bit more how to add in say FIFO as well. This is the weakness of DAVE, not enough variety in the solutions covered so that you do not need to hand craft code, ever.

Added note: The code supplied is probably XMC4400, deduced from searching for #defines that caused build to fail. I have duplicated this observation on the code thread.