2025-12-21 10:32 AM
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.
2025-12-21 11:08 AM
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 !
2025-12-21 11:11 AM - edited 2025-12-21 11:26 AM
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.
2025-12-21 11:30 AM
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.
2025-12-21 12:49 PM
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.