permanent I2S MCK output

[tilolutz]

Posted on May 28, 2012 at 10:30

Hi

I want to connect a PCM3168a audio codec to a STM32F407VG (Discovery board). The problem is the Codec is only alive when MCK is provided. Without MCK the control interface (i2c) is dead. Is use SPI3 in I2S mode for communication. Regarding documentation MCK is only active when a transfer is in progress. Does that mean the PLLI2S clock is only active when a transfer is in progress? My idea is to use MCO2 to provide the clock output of PLLI2S instead of using the MCK feature of the I2S to provide the clock for the coded. Will this work? #stm32f4-i2s

[Tesla DeLorean]

Posted on November 06, 2013 at 18:33

I haven't really be pondering the I2S clock output in the mean time, it's not something I use here in my designs.

The clocking rate of the PLLI2S is predicated by the setting in system_stm32f4xx.c, these might be different from the source tree I used in my examples, but are totally configurable. The pins are limited to ~84 MHz (perhaps 100 MHz optimistically, and correctly loaded), the MCO pins have a front end divider (1 - 5x as I recall), this permits a fractional version of a fast internal clock to be emitted, say the 168 MHz CPU, or 192 MHz PLLI2S, so it falls below the functional, or desirable, level indicated earlier.

[hualing_yu]

Posted on November 06, 2013 at 18:52

Always have trouble posting message here ...

Update- It's logic analyzer sample rate limitation.  Forgot about that.  It's now coming out correct, 38.4 MHz.  Sorry. I would still like to know, though, if i2s mclk really isn't meant for providing constant clk source for external module.  Thanks!

[Tesla DeLorean]

Posted on November 06, 2013 at 19:48

I would still like to know, though, if i2s mclk really isn't meant for providing constant clk source for external module.

Well it's part of a synchronous interface, the clock is there to shift data, and if there is no data, what's to clock? It's not wholly unreasonable for a codec that needs a constant clock to be generating it for itself, perhaps with a crystal at a desirable magic frequency. The clocking and PLL's of the STM32 aren't really that flexible. Compared to some SoC and ASIC parts I've worked on they are pretty woeful. I've had to run STM32 parts at sub-maximal speeds so I can fit the frequency plan other components need, and the STM32 can generate. I've got a PCM interface in one of my designs, we use TIM units to generate clocks, and sync signals persistently to the system. Input/output of the audio is muted at the codec. The forum has issues with mobile devices, and some browsers. Seems to be tolerable in FireFox provided it hasn't logged me out, at least the Back Button keeps the post when it errors.

[hualing_yu]

Posted on November 07, 2013 at 03:42

I even couldn't log in for 4 times! Finally this time it let me write and hope I can send it out in the end.  I am using Firefox.

I thought i2s doesn't need mclk to work but, you are right, all processes, ADC/DAC  etc on audio data path on audio board only need to be clocked while there are data to process.  That's probably what mclk is meant for. ''I've got a PCM interface in one of my designs, we use TIM units to generate clocks, and sync signals persistently to the system. Input/output of the audio is muted at the codec. '' Does this mean that we can use two clock sources for the audio board: one stable but less accurate for audio board system general process, and the other, mclk, come and go with audio data?  Maybe that's the better design, as long as it can work out on the audio board?  Thanks!

[hualing_yu]

Posted on November 13, 2013 at 22:29