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.
1.
>my only concern with using an oscillator vs MSI is whether the oscillator will draw more current
see ds:
...about 8mA for the ASFL1-12.288MHZ-EC-T .
2.
Try using the ASFL1-12.288MHZ-EC-T , to check, how long its playing fine and /stuttered (this indicates how much different the "48k" are ) .
20 secs for this "fine and /stuttered" sound indicates : one of the clocks is "bad" , probably the clock from MSI ;
20 x 48k = ~ 1 Mio samples , for 2k samples "drift" , so 2/1000 = 0.2 % one clock is wrong.
This is to be expected for the MSI...
3. ...so MSI too bad for audio, i think. If want low power HSE , use a 12.288 crystal , as HSE .
It will need only 0.5 mA about:
But for now : use the ASFL1-12.288MH , to check, what "drift time" we get with correct 12.288 source.
I found a clue why the SAI EXT CLOCK is not working.
I stepped through the intitilisation (SAI B is currently configured as a Tx master) and when it reaches the function RCCEx_GetSAIxPeriphCLKFreq the value for srcclk = 0 (see line 13 in the code snippet below) but I would expect it to be RCC_SAI1CLKSOURCE_PIN....
static uint32_t RCCEx_GetSAIxPeriphCLKFreq(uint32_t PeriphClk, uint32_t InputFrequency)
{
uint32_t frequency = 0U;
uint32_t srcclk = 0U;
uint32_t pllvco, plln; /* no init needed */
#if defined(RCC_PLLP_SUPPORT)
uint32_t pllp = 0U;
#endif /* RCC_PLLP_SUPPORT */
/* Handle SAIs */
if(PeriphClk == RCC_PERIPHCLK_SAI1)
{
srcclk = __HAL_RCC_GET_SAI1_SOURCE();
if(srcclk == RCC_SAI1CLKSOURCE_PIN)
{
frequency = EXTERNAL_SAI1_CLOCK_VALUE;
}
/* Else, PLL clock output to check below */
}
__HAL_RCC_GET_SAI1_SOURCE() reads the register RCC->CCIPR and I can see SAI1SEL is 0x0...
So why is SAI1SEL not set to '11' as shown in the refernce manual...
I've selected it CubeMX....
UPDATE: I set a breakpoint in the function RCCEx_GetSAIxPeriphCLKFreq and manually changed the value of SAI1SEL from 0x0 to 0x3 and the SCK and FS now work and the BT audio plays.
However, the problem still exists despite using the oscillator instead of MSI.
It plays the audio from the BT401 and for ~20 seconds its fine and the next ~20 seconds it still sounds like static/stutter. This cycle repeats
And I still don't know why SAI EXT CLOCK is not being configured by the software, I only got it working by manually modifying the SAI1SEL register.
UPDATE 2: It looks like the SAI EXT CLOCK is defined and exectuted in HAL_SAI_MspInit....
void HAL_SAI_MspInit(SAI_HandleTypeDef* hsai)
{
GPIO_InitTypeDef GPIO_InitStruct;
RCC_PeriphCLKInitTypeDef PeriphClkInit = {0};
/* SAI1 */
if(hsai->Instance==SAI1_Block_A)
{
/* Peripheral clock enable */
/** Initializes the peripherals clock
*/
PeriphClkInit.Sai1ClockSelection = RCC_SAI1CLKSOURCE_PIN;
if (HAL_RCCEx_PeriphCLKConfig(&PeriphClkInit) != HAL_OK)
{
Error_Handler();
}
But it seems that HAL_RCCEx_PeriphCLKConfig is not writing the value RCC_SAI1CLKSOURCE_PIN to the SAI1SEL register ???
