STM32G4 TCXO

[CrazyChel]

Please let me know if there are any hardware or sofware specifics for connecting TCXO to the STM32G474 series? What should pay special attention to?

I use FT2MN at 40 MHz. Its output was connected through a 10 pF capacitor and a 220 Ohm resistor, in series, to PF0 RCC_OSC_IN.
I'm running CubeIDE 1.16.0.

Unfortunately this doesn't work, I'll use a primitive for testing:

  while (1)
  {
  HAL_GPIO_TogglePin(GPIOC, LED_G_Pin);
  HAL_Delay(100);
    /* USER CODE END WHILE */

    /* USER CODE BEGIN 3 */
  }

When power is supplied, the LED_G lights up constantly. After pressing the reset button, it turns off and does not turn on again. If I turn the power off and on again, everything repeats itself.

When I change the configuration to the built-in RC generator. The LED_G flashes as specified by the program, the reset button works correctly.

I tried to see what happens at the input PF0 with my DSO2D15 oscilloscope, the declared band is 150 MHz, with the original probe in the 1:10 mode. I am not sure about the reliability of the results, especially regarding the amplitude. There I see a truncated sine wave that goes negative to 200 mV and positive to 220 mV. Accordingly, the full amplitude is 420 mV. Directly at the output of the TCXO, the amplitude is 1.2 V, and it almost does not go to negative. I didn't see a significant DC component there.

[Tesla DeLorean]

Make sure BOOT0 is pulled LOW

Instrument Error_Handler and HardFault_Handler to know if reaching those.

[Peter BENSCH · Accepted solution]

First of all: you must not connect the TCXO FT2MN to the OSC_IN via a capacitor, but directly. Otherwise you remove the DC offset and the signal becomes symmetrical to GND, which the STM32 can no longer process.

Then: the FT2MN may still have too small a signal: the data sheet says 0.8Vpp, but your measurements go in this direction if I remove your RC filter. In the data sheet for the STM32G474 you will find the necessary connection conditions under 5.3.7, according to which VHSEH must reach at least 0.7*VDD, i.e. 2.31V at 3.3V. So if the TCXO actually only supplies 0.8V at the peak, its signal is too small for the STM32.

Regards
/Peter

[CrazyChel]

Thanks!

Boot0 connected to ground wia 10K resistor.
Code from hard fault handler in stm32g4xx_it.c:

void HardFault_Handler(void)
{
  /* USER CODE BEGIN HardFault_IRQn 0 */
	HAL_GPIO_WritePin(GPIOC, LED_R_Pin, SET);
  /* USER CODE END HardFault_IRQn 0 */
  while (1)
  {
    /* USER CODE BEGIN W1_HardFault_IRQn 0 */
    /* USER CODE END W1_HardFault_IRQn 0 */
  }
}

LED_R don't turn on. I think he just doesn't have time. Because it really looks exactly like a hard fault.
I even created a separate project for testing that has nothing but these two LEDs.

[Andrew Neil]

---

@CrazyChel wrote:

Please let me know if there are any hardware or sofware specifics for connecting TCXO to the STM32G474 series? .

---

Nothing specific to TCXO: as far as the STM32 is concerned, it's just an external clock signal - so it must meet the same requirements as any other external clock signal.

https://community.st.com/t5/stm32-mcus-products/mems-oscillators-not-compatible-with-stm32f1-and-stm32l1-series/m-p/654210

[Andrew Neil]

---

@CrazyChel wrote:

Code from hard fault handler .

---

How about Error_Handler() - usually created in main.c:

/* USER CODE END 4 */

/**
  * @brief  This function is executed in case of error occurrence.
  * @retval None
  */
void Error_Handler(void)
{
  /* USER CODE BEGIN Error_Handler_Debug */
  /* User can add his own implementation to report the HAL error return state */
  __disable_irq();
  while (1)
  {
  }
  /* USER CODE END Error_Handler_Debug */
}

[CrazyChel]

Thanks!

I add:

void Error_Handler(void)
{
  /* USER CODE BEGIN Error_Handler_Debug */
	HAL_GPIO_WritePin(GPIOC, LED_R_Pin, SET);
  /* User can add his own implementation to report the HAL error return state */
  __disable_irq();
  while (1)
  {
  }
  /* USER CODE END Error_Handler_Debug */
}

Nothing changed unfortunately. I think that nothing will change until the amplitude at the input of PF0 reaches the threshold values.

[TDK]

Did you hook it up directly to the pin as @Peter BENSCH suggested?

The chip boots up using the HSI as the clock. Should be able to debug and step through program to find out what is going wrong.

[CrazyChel]

Yes, I wired it direct, also I resoldered the controller just in case. Now it simply does not start in HSI mode. Everything works in RC mode.
I also tested my oscilloscope with a reference generator and a reference oscilloscope. It turned out that at 40 MHz, my oscilloscope overestimated the value by 2 times. Therefore, the amplitude at the output of the generator is no more than 0.6 V. According to the data sheet on the STM, the input of PF0 should be much higher.

[TDK]

Connecting a probe to a clock line adds capacitance and pulls the line down.

If it doesn't start up at all, something is wrong with the hardware. That's not something the HSE can affect. What happens when you try to debug?