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)



(In the stm32CubeIDE)

 

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.

 

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.

Sorry, I mean to say no High Speed external crystal support??

 

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.

 

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!

 

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?

 

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)

 

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.

 

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)

 

Move up to the next size chip, 48-pin has OSC_IN OSC_OUT pins. No big deal.

 

Move up to the next size chip, 48-pin has OSC_IN OSC_OUT pins. No big deal.

Yes, did that

 

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.

 

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.

 

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.

 

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.

 

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