STM32F407, I2S with 8bit data format

[daniele]

Posted on April 24, 2014 at 19:43

Hi,

I have to revceive data from a device that is sending I2S with 8 bit data format....

The smallest I see is the 

I2S_DataFormat_16b,...

Is there a way that I can receive correctly this 8 bit data format?

Thanks

[Tesla DeLorean]

Posted on April 24, 2014 at 21:13

Slave Mode SPI? Otherwise probably not.

[daniele]

Posted on April 24, 2014 at 21:31

Hi,

I have to play the role of slave only.

What exactly do you suggest?

To use as SPI slave and trash all the 9th bit? Or to play somehow with chip select?

[Tesla DeLorean]

Posted on April 24, 2014 at 22:08

To use as SPI slave and trash all the 9th bit? Or to play somehow with chip select?

Yeah, I'm not familiar with any 9-bit issues. I'm familiar with streams where the WS toggles for left/right channels, and a PCM mode where WS indicated the next frame.

If the channel remains on, and synchronous, I'd imagine you could capture the stream and extract the bits/bytes you need. Initial synchronization is perhaps a little problematic. You could perhaps measure the WS edge, wrt RXNE?

Perhaps you can do something with a CPLD?

[waclawek.jan]

Posted on April 24, 2014 at 23:18

I never heard of 8-bit I2S, although the specification does not exclude it. Is it an 8-bit frame (i.e. 8 clocks between WS edges), or some other clock scheme? Could you please post link to the device's datasheet, or at least its timing diagram?

Why don't you simply try. If it *is* an 8-bit *frame*, it will work with the I2S module in STM32 being set to 16-bit format. There is a requirement to start the I2S module when WS is in inactive state (see errata) so obey that.

JW

[daniele]

Posted on April 25, 2014 at 06:05

Hi,

I have to admit that I'm not an expert of I2S, butlooks like a ''proper'' 8 bit frame. (see attachement)

Can you tell me where I can find the mentioned errata ?

Thanks

________________

Attachments :

I2S.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0jn&d=%2Fa%2F0X0000000bd9%2FL5gJlHdhTnzielPv_tfkC7bGqvIdhHnuPjJrBB4GG_o&asPdf=false

[daniele]

Posted on April 25, 2014 at 09:34

I could manage that it is sending 16 bits.

But I still not get what I see on the oscilloscope (look annex).

The errata tells:

In slave mode the WS signal level is used only to start the communication. If the I2S (inslave mode) is enabled while the master is already sending the clock and the WS signallevel is low (for I2S protocol) or is high (for the LSB or MSB-justified mode), the slave startscommunicating data immediately. In this case the master and slave will be desynchronized throughout the whole communication.

Workaround

The I2S peripheral must be enabled when the external master sets the WS line at:

(A)– High level when the I2S protocol is selected.

(B)– Low level when the LSB or MSB-justified mode is selected.

Now I do not know how to interpret it, and I'm not sure what shall I do on my case.

From the 16 bits I only need the first 8 that are sent (the other I can trash).

Question1:

''..The I2S peripheral must be enabled when the external master sets the WS line at...

Means that I2S peripherial must be enabled BEFORE the external

or

Means that I2S peripherial must be enabled AFTER the external

Question2: [UPDATE: I think that I should use the 1) because I have the dummy bit]

For this signal,what shall I select as standard?

1)

I2S_Standard_Phillips and consider workaround A)

2)

I2S_Standard_MSB

and consider workaround B)

Question3:

Where can I find some documentation about those standards (Philips, MSB, LSB, PCMshort...)?

________________

Attachments :

I006_I2S_16bit_ok.bmp : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0hd&d=%2Fa%2F0X0000000bd8%2FySDrLiQ36oqCd9E_IuJAdhxJHiyzkp0YQQsQbo.jGp4&asPdf=false

[waclawek.jan]

Posted on April 25, 2014 at 13:11

> I could manage that it is sending 16 bits.

It is 17 bits frame. I am afraid the SPI/I2S module in STM32 is not that flexible that it could cope with it - it supports only fixed length 16/32-bit frames. Strictly speaking, the I2S implementation here does not conform to the I2S specification, which allows arbitrary bit-length frames as long as they contain at least as much bits as the co/dec needs.

And it's not I2S either - I2S is stereo, WS determining the left-right (it's often called LRCK) sample. This one resembles what in the ST manual is called PCM. 

I believe, you *could* receive the data even when transmitted in non-16-bit frame, but at the cost of them being shifted by 1 bit in each read word, so that you would need to reconstruct them ''manually'' in software. Additionally, you lose the ability to detect synchronization errors, and the frame error flag will be always on.

Coincidentally, somebody else has described a similar problem in a parallel thread:

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fSTM32F4%20I2S%20Frame%20Error&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&TopicsView=https%3A%2F%2Fmy.st.com%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2FAllItems.aspx&currentviews=8

JW

PS.

Where can I find some documentation about those standards (Philips, MSB, LSB, PCMshort...)?

For I2S (Philips), simply google for ''I2S specification''. I am not aware of any formal document specifying MSB/LSB and I believe these are ad-hoc protocols created by competing companies, for example what is here described as LSB I used to find under ''Sony-I2S'' header. in various materials. PCM probably originates in the phone industry, but I am not aware of any standard for that either.

[daniele]

Posted on April 25, 2014 at 13:21

I found out on one document the difference between the standards.

The Philips one for the 16 bits has the 17clocks and the first clock is not used for a bit transfer.

The PCMshort has 16clocks and uses the first clock for a bit.

Finally I could get my data on this way:

- configure the sender to generate 16 clocks

- I use the PCMshort standard and at interrupt I just take what I need

myData = (uint8_t)(rxData>>7)

Later I will have a look to the parallel item.. :)

Thanks to participate at the discussion and to give me some hints.

[waclawek.jan]

Posted on April 25, 2014 at 13:38

> The PCMshort has 16clocks and uses the first clock for a bit.

Then that should work with the STM32.

> Later I will have a look to the parallel item.. :)

You don't need to, as you've found the solution in configuration of the other chip.

JW

[Tesla DeLorean]

Posted on April 25, 2014 at 14:13

My recollection of I2S is that it comes from the CD player chipsets and DACs, where left/right channels were shifted as a continuous stream 16-bit left/right channel and the WS indicating which channel was being sent, and providing synchronization.

It has been subsequently bastardized into other formats (to avoid patent/licensing issues and litigation), including apparently mono PCM streams, bit direction, stuffing in random bits, and being of random bit lengths and coding schemes. These would be PCM formats, that some codecs can generate or source, but are technically serial sound formats, not I2S. Controllers offering I2S, may also be configurable in other ways.

Pretty sure the STM32 will work with CD/DVD audio codecs and dacs, but it's definitely not sufficiently flexible for Telco audio formats, or codecs that invent their own standards.