Trying to source a 12.288MHz clock for STM32L433

[freeflyer]

I am trying to source a 12.288MHz clock for an STM32L433 but having difficulties finding something.

The clock is required for I2S playback with a bluetooth receiver (BT401).

I have tried using the internal MSI RC to generate the 12.288MHz clock for SAI,  but the BT401 is misbehaving so it might be because the MSI RC clock has too much jitter.

I was wondering if a ASFL1-12.288MHZ-EC-T would be suitable for the clock source for the SAI external clock input....

https://uk.rs-online.com/web/p/crystal-oscillators/2403583

Below is the setup... 

The I2S amplifier (MAX98357A) seems to work fine with the 12.288MHz clock generated by the internal MSI RC and PLL.

But the BT401 either requires multiple attempts to start playing and sometimes plays just a screeching sound for a few seconds then stops.  So I need to rule out whether the issue is caused by clock jitter by trying a more accurate clock source.

I am currently using the STM32L433 Nucleo board which has a footprint for an external HSE crystal, but I cannot find a crystal for that footpring with a 12.288MHz frequency.

The ASFL1-12.288MHZ-EC-T seems to be an all in one device, you just provide power and it generates the output clock.  So its not like a crystal which needs a special drive circuit ?

I have read the application note AN2867 Recommended resonators for STM32 MCUs/MPUs, but its complicated and just confused me.

[freeflyer]

Many thanks morries, its reassuring to hear that the ASFL1 is suitable and that you also had similar issues which were fixed by using a more accurate clock.  I checked the ASFL1 voltage and it is 3.3V.

On the Nucleo developmnet board I will have to 'dead-bug' wire the ASFL1 and capcacitor to test it, but I will be designing my own PCB once I have found a solution for this problem with the BT401.

PS.  The link to your website seems suspicious, it opens your page for a few seconds then opens some susupicous looking pages !

[AScha.3]

Hi, 

1. you again... :)

2. ASFL1-12.288MHZ is a oscillator, yes, just needs 3v3 and it will output 12.xx MHz .

3. You pic is bad/wrong: L433 master receive means: all arrows go from BT401 to the L433/SAI , as BT401 is "master" here, sending out BCK, LRCK , DAT .

4. you need no extra clock then, because its coming from BT401 and you cannot change the clock to any other source.  

5. > But the BT401 either requires multiple attempts to start playing 

Problem could be anything...first: IS bt401 master ? check with a scope, what happens on its output BCK, LRCK , DAT . I dont know, how you /or the BT chips handle a not existing connection , until you connect and send data.

So the problem might be: BT connection has to be stable and without dropouts, then output to dac should be fine.

Until stable data stream from bt401 is established , you should mute the sound output, as it will be useless noise.

[freeflyer]

Hi AScha.3, yes me again :)

I have got everything working nicely, other than the issue with the bluetooth receiver.

When we last discussed this, I had the BT401 as a master I2S and the STM32 as a slave I2S.

However, I had to swap this around because the BT401 I2S clocks were intermittent at powerup which meant the voice prompt (stored in external flash connected to the STM32 via SPI with DMA) which is called at power up stuttered.

In fact its a better solution to use the STM32 as the I2S master, because it removes dependancy on the BT401 to generate the I2s clocks.  This means that the voice prompts (which are critical to the system) will work even if the BT401 fails for some reason.

The STM32 outputs the bit clock and left/right clock to the BT401 and amplifier, the BT401 outputs data to the STM32 and the STM32 outputs data to the amplifier.

Below is the SAI configuratoin which should align with the block diagram...

This is all working correctly, other than the issue with playing audio from the BT401.

[AScha.3]

Hi,

i dont know, how the BT audio doing this - you have to search/read : the problem : who is the master (of clock for play audio) ; see , its always same problem: as long as data is handled as "data" , in web or PC ...no problem; if data is "music" or audio, its still data. BUT if it comes to real world -analog- we have to convert, from digital to analog, and this demands the correct time, data is coming to analog. So the last in chain, the DAC , has to get the defined clock rate, 44k1 or 48k ..., and all the line down, where data is coming from, has to adjust to this, to "play" perfect.

But in BT or PC there usually is a device, in PC called mixer, that decides to play ...48kHz . So all down the stream have to adjust to this. Or you can change the "master clock source" to ...the DAC , but this needs special adjustment in the transmission and devices...

So : can the BT be slave (for the data rate)? and the master clock coming from the L433 ? check this.

+

Imagine simple problem, i got when playing MP3 from web: my device has its clock from a crystal, making 44k1 audio. The server somewhere on this planet has its own clock , also from a crystal, sending data for "44k1 rate" , when i order next packet...etc. BUT crystals have not infinite precision, so my crystal might be 1/100000 faster than the server's crystal. Nothing happens, just i want more data from the "future" - until the limit of some buffer setting in the server is reached, maybe after 2 h continuous stream playing. Now the server will denie more fast/future data, and i have to adjust the timing in some way. Usually just a "dropout", and it will go on until again times are drifted apart too much. Or you make some intelligent adjustment, like inserting samples from time to time, to sync the "time" to the server.

[freeflyer]

The BT401 has two different I2S firmware versions, one is 48kHz and one is 44.1khz.  This is fixed and I have used the firmware where the sample rate is always 48Khz, regardless of the source.

The STM32 does output the I2S bit and LR clocks, I have cheked on the oscilloscope and it wouldnt work if this was not the case.

The BT401 was working correctly, with the exception that the initial play request would fail but subsequent play requests would work.

However, it has gradually become more unreliable and I thought it might be down the the development board setup using jumper wires.  I only have to move the wires slightly for it to start causing issues.  Jumper wires are not good when when the bit clock freqneuncy is 3.072MHz !  

I have a contact in China who supplies the BT401 module as well as the IC and he is supporting me with the development of the hardware.  For my custom PCB, I will not be using the BT401 module, instead I will use the IC with the antenna so it will be an all in one solution, rather than usung BT401 module.  

When you purchase the BT401 module from RS/Dfrobot the firmware only has the  DAC output, but this contact in China provides firmware that uses I2S.

Also the BT401 IC will only be used for a short duration (20 to 30 min) and then everything will power off.

[freeflyer]

I have fitted the ASFL1-12.288MHZ-EC-T but the STM32 is no longer generating the I2S clocks (bit clock & left/right clock) so my I2S audio has completely stopped working :(

The output of the ASFL1 is connected to pin PA0 of the STM32.

In CubeMX I enabled SAI Extern clock...

The SAI clock is configured to use SAI EXT...

I have checked the 12.288MHz output on a scope....

For reference, below is the clock configuration when I2S did work (with the exception of the BT issues).  This is when I used the internal MSI RC to generate the 12.288MHz clock...

The only thing that has changed is the SAI clock source, instead of using the internal MSI RC it is using the external SAI pin.

So why does it not work with the external SAI 12.288MHz clock ?

[freeflyer]

Is this a clue ?

If so it makes no sense, because it implies that SAI_EXTCLK on pin PA0 is an output due to the fact the GPIO mode is push/pull....

So if its an output, how can it be used to clock the SAI peripheral ???

[AScha.3]

Really only switching the clock mux to sai_ext ?   It should work as before.

Switching back to pll_sai ...working then ?

+

>I only have to move the wires slightly for it to start causing issues.

So this is "normal" , if timing is critical you cannot have long free air wires. 

[freeflyer]

Correct, it does not work with the SAI1_EXTCLK input. I even put the scope directly on the STM32 pin PA0 to make sure the clock was there. 
I looked at the bit clock and left/right clock on the scope and there was nothing there.  

if I revert back to the internal MSI RC as the clock source for SAI it generates the bit clock and left/right clock and plays the audio. 

it just does not seem to accept the external clock for some reason.