STM32G071KBT6, no crystal support?

Thread Starter

bug13

Joined Feb 13, 2012
2,002
Hi team

I am venturing into first ARM PCB design. While I figuring out what pins to connect to an external crystal, I can't find a OSC_OUT pin anywhere for my part? So I am guessing there is no High Speed External Crystal support for STM32G071KBT6?? Or I am missing something here??

I am using this STM32G071KBT6

Edit: clarify question regarding High Speed External Crystal support

(Table 12, or page 44 of the datasheet)

Screenshot 2020-12-11 113618.png

(In the stm32CubeIDE)
Screenshot 2020-12-11 112804.png
 
Last edited:

MrChips

Joined Oct 2, 2009
30,712
OSC32 connections are on pin-2 and pin-3.
You can put a 1MHz xtal there.

I am running a STM32L071 with the internal oscillator at 16MHz.
 

MrChips

Joined Oct 2, 2009
30,712
With low pin-count MCUs there is a trade-off between speed and low-power.

If you still need the speed you can use the internal 16MHz oscillator (HSI16). You can trim this but I have yet had a reason to do this.

For low power and RTC applications use the external 32768Hz xtal.
 

Thread Starter

bug13

Joined Feb 13, 2012
2,002
With low pin-count MCUs there is a trade-off between speed and low-power.

If you still need the speed you can use the internal 16MHz oscillator (HSI16). You can trim this but I have yet had a reason to do this.

For low power and RTC applications use the external 32768Hz xtal.
I don't really want to risk it by using HSI16, I am running a few high speed UARTs. Hence I need external crystal, I guess I will need to pick another chip. Doh!
 

Analog Ground

Joined Apr 24, 2019
460
The data sheet specifies crystal oscillator up to 48 MHz. See the data sheet, bottom of page 69 and page 70. It talks about connecting a crystal using HSE mode. Here is the bullet at the beginning of the data sheet. Also, see page 163 of the Reference Manual. Finally, the clock tree diagram on page 166 seems pretty definitive. Is the problem the OSC_IN and OSC_OUT are not available for your package?

STM32_Xtal.PNG
 
Last edited:

Thread Starter

bug13

Joined Feb 13, 2012
2,002
The data sheet specifies crystal oscillator up to 48 MHz. See the data sheet, bottom of page 69 and page 70. It talks about connecting a crystal using HSE mode. Here is the bullet at the beginning of the data sheet. Also, see page 163 of the Reference Manual.

View attachment 224597
Yup, I read that too, that's why I chose this part. But when I actually planning my schematic, I could not find the pins that can connect an external high speed crystal to it.

However I can find OSC_IN & OSC_OUT in the higher pin counts part, eg the same series but in LQFP48 package. (Not that the part I chose is low pin counts, it has 32 pins/30 IOs)
 

Analog Ground

Joined Apr 24, 2019
460
I guess you have worked out the HSI16 and the ~1% accuracy and baudrate generator don't work out for your UART? What baud rate? It seems odd to sell a part with crippled UARTs.
 

Thread Starter

bug13

Joined Feb 13, 2012
2,002
I guess you have worked out the HSI16 and the ~1% accuracy and baudrate generator don't work out for your UART? What baud rate? It seems odd to sell a part with crippled UARTs.
Good question, to be honest, I always use an external crystal if I ever need to use UART. As I simply don't want to risk it by not using one.
But I did a google after reading your reply, surprisingly, I couldn't find the UART timing tolerance requirements.

To answer your question, I need to run it at full speed (64MHz). And I need to use 5 UARTS at 115200. (1 RS485, 2 RS232 and 2 internal UARTs)
 

Analog Ground

Joined Apr 24, 2019
460
Yes, UART timing requirements are squishy. Here is a useful article.

https://www.allaboutcircuits.com/te...d-rate-clock-how-accurate-does-it-need-to-be/

I respect your decision to go with a different part and use a crystal. I would probably do the same. As an intellectual exercise, going with a 1%, 16 MHz source for a 115,200 receive clock is marginal, IMHO. If the baud rate generator can divide by 9, then the receive rate for x16 sampling is 111.1KBaud which is about 3.5% off. This seems marginal to me.
 

MrChips

Joined Oct 2, 2009
30,712
One point to keep in mind is if both ends of the UART interface are using 8MHz crystals which are commonly used, or MCU clocks of 16MHz or 64MHz then the error between UART baud clocks is minimal.

Furthermore, you are free to use any non-standard baud you choose, for example 1,000,000 baud.
 

Analog Ground

Joined Apr 24, 2019
460
Yes, UART timing requirements are squishy. Here is a useful article.

https://www.allaboutcircuits.com/te...d-rate-clock-how-accurate-does-it-need-to-be/

I respect your decision to go with a different part and use a crystal. I would probably do the same. As an intellectual exercise, going with a 1%, 16 MHz source for a 115,200 receive clock is marginal, IMHO. If the baud rate generator can divide by 9, then the receive rate for x16 sampling is 111.1KBaud which is about 3.5% off. This seems marginal to me.
Have you considered upping the 16 MHz with the PLL? Then, only the RC oscillator tolerance is in play and not the division issue. This is around 1% which is not too bad.
 

Thread Starter

bug13

Joined Feb 13, 2012
2,002
One point to keep in mind is if both ends of the UART interface are using 8MHz crystals which are commonly used, or MCU clocks of 16MHz or 64MHz then the error between UART baud clocks is minimal.

Furthermore, you are free to use any non-standard baud you choose, for example 1,000,000 baud.
Thanks for pointing this out, it's something good to keep in mind for future projects. For this one, I have to use 115200, and I need to interface other devices that I have no control off.
 

Thread Starter

bug13

Joined Feb 13, 2012
2,002
Have you considered upping the 16 MHz with the PLL? Then, only the RC oscillator tolerance is in play and not the division issue. This is around 1% which is not too bad.
Thanks for the link, that is a very good reference. I actually need to run at full speed (64M) with PLL. So it will actually work according to the math.

And the ST uart are sampling at 8 or 16 per bit anyway. So it's a lot better than 1 sample per bit as suggested in the article.

I will still use a crystal for this project however :)
 
Top