I2S at 384kHz... can it be done ?

[alberto239955_stm1_stmicro_com]

Posted on June 27, 2013 at 00:37

Hello,

  the I2S interface is specified up to 192kHz, and actually the  stm32f4xx_spi.h  file has defines from 8kHz up to 192kHz. I am wondering if anybody has ever tried to push the I2S interface up to 384kHz (and possibly beyond...). Were it possible, that would be very interesting for my product. Thanks for any feedback, positive or negative.

[Tesla DeLorean]

Posted on June 27, 2013 at 01:40

Perhaps you can restate the question, the bus can clearly go above 384 KHz, but that refers to a audio sample rate at some bit width and channel count. You'll need to quantify those requirements.

The SPI peripheral can be clocked out at rates >37 MHz PLLI2S has a working range 192 .. 432 MHz, and the I2S divider can clock at >150 MHz 64-bit (2x32-bit) @ 384 KHz equates to 24.576 MHz bit clock. I'd have to make a fitter/solver to get some ideal configuration settings, but looks doable.

[Tesla DeLorean]

Posted on June 27, 2013 at 02:10

Also, what level of bit rate error can you tolerate? These tend to climb as the rate goes up due to the lack of division/precision.

If you're not tied to USB (48 MHz), you could always start by using a more audio rate friendly magic crystal value.

[Tesla DeLorean]

Posted on June 27, 2013 at 06:15

target:24576000 Hz (384000 Hz, 64-bits)
24583333 38458333 -0.0298% : is2div= 3 i2sodd=0 plli2sn=295 plli2sr=2
24583333 38458333 -0.0298% : is2div= 2 i2sodd=0 plli2sn=295 plli2sr=3
245714571 383957143 +0.0186% : is2div= 3 i2sodd=1 plli2sn=344 plli2sr=2 (Optimal)

[Tesla DeLorean]

Posted on June 27, 2013 at 06:30

HSE:288 MHz pllm=12
target:24576000 Hz (384000 Hz, 64-bits)
24576000.000 384000.00000 +0.0000% : is2div= 2 i2sodd=0 plli2sn=192 plli2sr=2
24576000.000 384000.00000 +0.0000% : is2div= 2 i2sodd=1 plli2sn=240 plli2sr=2
24576000.000 384000.00000 -0.0000% : is2div= 3 i2sodd=0 plli2sn=288 plli2sr=2
24576000.000 384000.00000 -0.0000% : is2div= 2 i2sodd=0 plli2sn=288 plli2sr=3
24576000.000 384000.00000 +0.0000% : is2div= 3 i2sodd=1 plli2sn=336 plli2sr=2
24576000.000 384000.00000 +0.0000% : is2div= 2 i2sodd=1 plli2sn=360 plli2sr=3
24576000.000 384000.00000 +0.0000% : is2div= 2 i2sodd=0 plli2sn=384 plli2sr=4

[waclawek.jan]

Posted on June 27, 2013 at 09:22

> HSE:288 MHz
 48MHz for USB from this crystal should be viable. The only problem is then the built-in bootloader.
 ---
 The new rev4 datasheet for STM32F4xx brought much confusion to the max.I2S frequency. As older revisions stated invariably ''TBD'', the only limitation appeared to be the ''max. 192 MHz'' from RCC_PLLI2SCFGR description in RM0 Now the datasheet states in footnote 2 of Table 56 that ''The maximum value of 256 x FS is 42 MHz (APB1 maximum frequency).'' That would mean, that maximum sampling frequency would be around 164kHz, making even 192kHz unattainable, which I doubt is the case. The note under Table 56 is not very helpful either, stating rather cryptically that ''Fs maximum value is supported for each mode/condition''.
 This sloppy approach from ST towards the data they publish, makes me sad.
 JW

[alberto239955_stm1_stmicro_com]

Posted on June 27, 2013 at 13:14

> Perhaps you can restate the question, the bus can clearly go above 384 KHz, but that refers to a

> audio sample rate at some bit width and channel count. You'll need to quantify those requirements. Presently I use I2S to bring I/Q data from an RF digitizer, followed by a DDC (Digital Down Converter) implemented in a FPGA, on the same board, at a rate of 192 kilosamples per second. Each sample consists of two words (I and Q) of 32 bit each. I and Q are mapped into what I2S standard calls left and right channel. Everything works perfectly. USB is not involved in the picture, HSE is 8 MHz PLL'ed up to 168 MHz. Now there is the need to go beyond 192 ks/sec, theoretically up to what the FPGA code is capable of, i.e. 6,144 ks/sec.  Of course this is just theory, because then the ARM M4F chip will not have enough processing power to cope with that data rate. But, at least as long as the CPU can process it, a higher data rate would be quite desirable. I used for the current code the routines that I found defined in  stm32f4xx_spi.c, namely the I2S_Init() with its parameters, which however do not contemplate the case of speeds higher than 192 ks/sec.  I suppose I have to go down to bare register programming to achieve higher rates, and maybe a short snippet of code as an example would be helpful.   Thanks.

[Tesla DeLorean]

Posted on June 27, 2013 at 13:17

This sloppy approach from ST towards the data they publish, makes me sad.

Indeed there do appear to be a number of internal inconsistencies, and some very awkward language. If the designer can't express the function via language, perhaps a diagram would help indicating the function, clock domains and critical paths. I basically tried to identify the critical paths by reading into the various limits and examples presented. The highest used clock driving the divider chain is >150 MHz, the stated limit is 192 MHz. Elsewhere the shifting unit is limited to 37.5 MHz, and I scratch my head wondering why not 42 MHz

[waclawek.jan]

Posted on June 27, 2013 at 13:25

> Elsewhere the shifting unit is limited to 37.5 MHz,

Where? JW

[Tesla DeLorean]

Posted on June 27, 2013 at 13:33

I suppose I have to go down to bare register programming to achieve higher rates, and maybe a short snippet of code as an example would be helpful.

The SPI library code looks to compute the register settings, and would be totally agnostic if not for the ASSERT, and an integer requirement for the PLL clock. Honestly I think that could easily be remedied with a swift edit of the stm32f4xx_spi.c/.h files. The I2S_InitStruct->I2S_AudioFreq field is just the numeric sample rate.