Using audio clock (22.5792MHz or 24.576MHz) as STM system clock

[John Kenny]

Posted on April 26, 2018 at 16:37

I've seen STM audio boards (SD card player) with only two audio clocks (5792MHz & 576MHz) on the pcb. Depending on the speed family of the audio file being read, the STM uC is using the relevant audio clock as its system clock. Does anyone have a link to the code which does this, please?

Note: this post was migrated and contained many threaded conversations, some content may be missing.

[Tesla DeLorean]

Posted on April 26, 2018 at 16:52

What board? What STM32? Lots of combinations, lets try and narrow it down a bit.

Most STM32 can take external sources in range 4-50 MHz, or crystals upto 25 or 26 MHz, these don't have to be integers. The part can clock from HSI also, and PLL can be used for I2S. The I2S clock can be feed from a different pin as I recall. Clock sources can be transitioned between HSI, HSE and PLL, you have to stop the PLL to reconfigure it, so switch to a clock that is still running to keep the synchronous machine running.

You'd need to define HSE_VALUE correctly, and fiddle with PLL settings (simple gear ratios)

[John Kenny]

Posted on April 26, 2018 at 17:00

Thanks Clive

Here's the board

https://aealicdn.com/kf/HTB1yQHxeoo09KJjSZFDq6z9npXaM.jpg

- it's as simple as it gets - STM32F4 read SD card into memory chip & outputs I2S audio signals

Other side of board is just screen & control buttons

As you can see just two audio clocks on pcb so STM is switching between these as system clock depending on the samplerate of the audio file.

The benefit is that the system clock & I2S clock are always synchronised so no clock crossing domain issues

[John Kenny]

Posted on April 26, 2018 at 17:40

Just to describe the operation of the board some more - there is an enable signal pcb track to each clock & each clock signal is routed through a resistor back to one clock input pin on the STM. So the correct clock is enabled depending on what samplerate audio file is being read i.e 22.5792MHz clock is enabled if audio file is 44.1KHz, 88.2KHz, 176KHz, 352KHz & 24.576MHz clock is enabled for the other speed family 48, 96,192, 384KHz samplerate

Now the STM must have a system clock it uses to read the audio file off the SD card before it has analysed the samplerate & set the correct audio clock (which then becomes the new system clock).

 I'm wondering how this is all done - I guess the system clock be changed when the audio files has been read & copied to the pcb memory chip?

Just wondering if anyone has encountered this before & have any pointers?

[Tesla DeLorean]

Posted on April 26, 2018 at 17:57

Looks like there is a mux chip, or switch, 6-pin chip on right of oscillators.

You can shift speeds in much the same way you'd change gears in a manual transmission car.

The CPU could run of the PLL+HSI, and switch between HSI, HSE, PLL as sources, and drive the GPIO as required. You'd need to code to 'clutch' the transfer, but just a matter of reconfiguring/sequencing a bunch of RCC registers.

[John Kenny]

Posted on April 26, 2018 at 18:53

Thanks Clive but that other chip is a Winbond 2464 which I believe is flash memory, probably containing the firmware or some such? 

Are there any code examples for the type of clock clutching you mention? 

[Tesla DeLorean]

Posted on April 26, 2018 at 19:15

Sorry the one on the left, 6-pin uDFN type part rather than the 8-pin SOIC

Sort of code I'd write to order.

In HAL the sort of thing where you'd call 

HAL_RCC_ClockConfig()/

HAL_RCC_OscConfig() in stages

RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI;

RCC_OscInitStruct.HSIState = RCC_HSI_ON;

...

HAL_RCC_OscConfig(&RCC_OscInitStruct)

...

RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_HSI; // Down Shift to HSI (assumed on)

HAL_RCC_ClockConfig()

..

Might want to turn off PLL/HSE with more dancing around with 

HAL_RCC_OscConfig()

GPIO Switch Source

RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;

RCC_OscInitStruct.HSEState = RCC_HSE_BYPASS; RCC_OscInitStruct.HSIState = RCC_HSI_ON;RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON; RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;

RCC_OscInitStruct.PLL.PLL Settings

...

HAL_RCC_OscConfig(&RCC_OscInitStruct)

..

RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK; // Switch to newly locked PLL

HAL_RCC_ClockConfig()

With RCC register directly sequencing could be handled more cleanly (HAL wants to bang on dozens of settings, which might resolve to a single bit)

[John Kenny]

Posted on April 26, 2018 at 19:28

Oh, that 6 pin chip handles the clock enable signals - not exactly sure Anding or some such - it doesn't touch the clock signals.

Thanks for the code snippets - can I PM you for possible coding job - if you are open for that sort of work or if you would know someone who is?

[Tesla DeLorean]

Posted on April 26, 2018 at 20:13

I dabble, and am open to reasonable offers for my time. Been more than a decade since I worked on media players.

Schematics here would be helpful. The SDIO peripheral clocks off the PLL. The chip supports multiple clock domains, I2S/SAI definitely built to clock off different sources, and different PLL taps.

[John Kenny]

Posted on April 26, 2018 at 21:02

Great -I'll contactvia PM

Looking at the chips on the board would seem to suggest the following high-level overview of its operation:

- audio file begun reading from SD card & written to 8Mb ISSI static RAM

- static RAM used as read/write buffer controlled by STM uC

- audio samplerate established during initial read of file & before audio samples are read from static RAM, system clock is changed to either one of the audio clocks & remains so for the duration of the track

- WAV or DSD file handling

- I2S signals output

- interrupts for button events - next track, previous track, reset