Why does the Crystal Clock on STM32F103 have an offset and why is the microcontroller very sensitive to this offset?

[FMali.1]

Hi,

I am currently having trouble with a Hard fault issue that I cannot understand and I was hoping someone might have come across a similar issue. I have a Crystal Oscillator with a 16MHZ clock at the input. I use the MCO pin from the microcontroller to provide clock to an additional ASIC. I have observed that the microcontroller is very sensitive to the offset of the clock input. Additionally, the microcontroller works as expected at room temperature but as soon as I increase the temperature to 70°C the MCU enters into hard fault whenever I restart the MCU. It can work perfectly fine for temperatures beyond 90°C as long as I do not restart the MCU. The clock input is always okay also when it runs itself into a Hard Fault.

[Tesla DeLorean]

Check the PLL multiplier settings, and FLASH Wait States

Check HSE_VALUE define, most F1 expect an 8 MHz source

Check using BYPASS mode for external sources (ie TCXO).

[FMali.1]

I am using a STM32F103C8T7 and it supports 16MHz. The PLL multiplier is 3 and all the clock for the peripherals should also be ok. Attached you can see the screenshot with the current clock configuration. Flash latency is set at 1 wait state. I have however also test it with 2 wait states without any advantage. I try using the bypass mode, havent tried it yet. I have however used the RCC_HSEConfig(RCC_HSE_ON); to provide the external clock.

[Tesla DeLorean]

Yeah, I think fPLLCOMP needs to be 4 MHz, the 8 MHz sources they divide by 2

void SystemClock_Config(void)
{
 RCC_ClkInitTypeDef clkinitstruct = {0};
 RCC_OscInitTypeDef oscinitstruct = {0};
 
 /* Enable HSE Oscillator and activate PLL with HSE as source */
 oscinitstruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
 oscinitstruct.HSEState = RCC_HSE_ON; // RCC_HSE_BYPASS; // External Source
 oscinitstruct.HSEPredivValue = RCC_HSE_PREDIV_DIV4; // 4 MHz PLL comparison
 oscinitstruct.PLL.PLLState = RCC_PLL_ON;
 oscinitstruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
 oscinitstruct.PLL.PLLMUL = RCC_PLL_MUL12; // 4x12 48 MHz
 
 if (HAL_RCC_OscConfig(&oscinitstruct)!= HAL_OK)
 {
 /* Initialization Error */
 while(1);
 }
 
 /* Select PLL as system clock source and configure the HCLK, PCLK1 and PCLK2
 clocks dividers */
 clkinitstruct.ClockType = (RCC_CLOCKTYPE_SYSCLK | RCC_CLOCKTYPE_HCLK | RCC_CLOCKTYPE_PCLK1 | RCC_CLOCKTYPE_PCLK2);
 clkinitstruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
 clkinitstruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
 clkinitstruct.APB2CLKDivider = RCC_HCLK_DIV1; // 72 MHz Max
 clkinitstruct.APB1CLKDivider = RCC_HCLK_DIV2; // 36 MHz Max
 if (HAL_RCC_ClockConfig(&clkinitstruct, FLASH_LATENCY_1)!= HAL_OK)
 {
 /* Initialization Error */
 while(1);
 }
}

[FMali.1]

I also do not need to bypass the HSE. It has to be enabled for external Quartz Oscillator. And that is also correct. But still, why does the clock generated with the inverter of a MCU have an offset of 1.2V. This is what is strange to me. Does the STM MCUs always have an offset?

[Tesla DeLorean]

Typically crystals aren't driven rail-to-rail, 1.2 Vpp would be typical, the inverter acts more like an amplifier, driving the other side of the crystal with an anti-phase signal.

https://www.st.com/resource/en/application_note/an2867-oscillator-design-guide-for-stm8afals-stm32-mcus-and-mpus-stmicroelectronics.pdf