cancel
Showing results for 
Search instead for 
Did you mean: 

External clock generation at non-multiple of system clock

Paul UHS
Associate II
Posted on April 08, 2013 at 09:24

Hi All,

   

I am trying to produce a 256 kHz frequency clock for use with audio codecs. I am trying to produce this 256kHz freq from the 120MHz system clock on the STM32F207 series.

I would like to use the timers to produce this 256kHz clock, however 256kHz does not evenly divide into 120MHz. (120Mhz/256kHz = 468.75)

    

Does anyone know of a way to produce a non-multiple of the system clock by using a combination of timers, and cascading timers.

I have found one way to produce 192MHz from the I2S PLL, and then output on MCO 6.4MHz, which can then be divided down to 256KHz, but this requires two pins, 1 for the MCO pin and 1 for external clock input. I would prefer to be able to just use internal timers and get back two micro controller pins.

Any help find a solution to this would be great.

#fitter #external-clock #advanced-timers #clocks #magic-crystals #doughnuts
22 REPLIES 22
Paul UHS
Associate II
Posted on April 09, 2013 at 14:59

Ok lets see if I have got this right.

Currently I am out of SPI modules on the STM32. As I am using SPI for:

1) SPI Master to Flash

2) SPI For Audio to SLIC

3) SPI for another audio path

But if I were to replace 1) with a Syncronous USART (that does not drive the Clock while Start/Stop bits are sent), this would give me 1 free SPI.

So now I have two SPI's free for Audio to SLIC. I would use these SPI ports as follows

1) Setup 1 as an I2S module, which will act as I2S Half Duplex TX

2) Setup 2 as an I2S module slave which will act as Half Duplex RX

OR

1) Setup 1 as an I2S module, which will only output a clock at 256KHz

2) Setup 2 as an SPI Slave, which will take the Clock from I2S module, and handle both TX and RX as full duplex

I think that will do it. No need for some non-standard clock rate, and takes advantage of the I2S PLL's. I still keep all the SPI required functionality (albeit at a 10% slow down, but that's fine). I can even take advantage of I2S (which is fantastic!)

Anyone spot any problems before I go about cutting and strapping?

Paul UHS
Associate II
Posted on April 09, 2013 at 15:17

It would seem option #2 of using an SPI bus in slave mode works best, rather than using two I2S modules in half duplex.

With two in half duplex, I need to connect FRAME and CLK between the two I2S modules. This requires one more pin (the FRAME Slave pin).

List of pins are:

1) I2S_MASTER_CLK

2) I2S_MASTER_FRAME

3) I2S_MASTER_TX

4) I2S_SLAVE_CLK (connected to I2S_MASTER_CLK)

5) I2S_SLAVE_FRAME (connected to I2S_MASTER_FRAME)

6) I2S_SLAVE_RX

While the pin count using 1 I2S module & 1 SPI module in slave mode:

1) I2S_CLK

2) I2S_TX

3) I2S_FRAME (possibly generated by GPIO via DMA to allow SPI syncronisation)

4) SPI_SLAVE_CLK (connected to I2S_CLK)

5) SPI_SLAVE_MISO

Posted on April 10, 2013 at 09:17

> [with USART in synchronous mode] I still keep all the SPI required functionality (albeit at a 10% slow down, but that's fine).

It's not -10% if you are after the highest attainable speeds - while the max. SPI clock is fPCLK/2, the highest USART clock is fPCLK/8, IIRC. So it's more like -90%. Whether this is detrimental in your application, I don't know.

JW