Possible to use USB in STM32G0B0KE (32pin)?

[MichaelSweden]

In datasheet STM32G0B0KE/CE/RE/VE, DS13565 Rev 2, page 28/105 this can be read:

"The embedded USB controller cannot be used on STM32G0B0KE as this device does not provide an HSE oscillator input."

As it is written on same page "the clock source must use a HSE crystal oscillator", HSE must be used for USB functionality. Since it is no pins for HSE crystal in the 32 pin package, it will be impossible to use HSE crystal. HOWEVER it is possible to set HSE in BYPASS and connect an external clock oscillator. If this external clock is accurate it would be possible to use USB on this device - wouldn't it?

However I also found this:

page 9: USB=None for K

page 14: "USB on pins PA11/PA12 (except for STM32G0B0KE)"

page 37: "USB-related alternate or additional functions do not apply to 32-pin package"

page 87: "The STM32G0B0KE/CE/RE/VE USB interface "

page 104: " to indicate the impossibility of using USB controller on STM32G0B0KE"

So I am confused. Is the USB block in the device or not?

PS. Please make a variant of STM32G0B0KE with HSE Crystal pins.

[Tesla DeLorean]

Looking like it's not. While the die might be the same, ST does have parts where they do not test or enable the USB IP, this generally reduces test time, and presumably license payments.

Some of ST's choices on low pin count devices have been very frustrating and limiting over the years.

[TDK]

It is selectable in CubeMX, although that doesn't mean a ton.

[Viktor POHORELY]

USB on 32 pin STM32G0B0KE can't be used, because you have no clock source precise enough available on this device. On STM32G0B0xx devices, USB rely on an external crystal oscillator, which can't be connected as it's pads are not present on the package.

So, at the end, it does not matter if USB signals are present on the GPIO's (well, they are), it would not run on that device. That's why there is 0 USB's in the table of the device features.

If you need to go for 32 pin device with USB, go for STM32G0B1KE.

[TDK]

As he explains quite clearly in the OP, HSE bypass can supply a sufficiently precise clock source as it does on many other chips.

[MichaelSweden]

Thanks for all answers. I'm still not sure about how it is with USB and how about HSE bypass... well let us take a deeper look into the datasheet.

Page 31: No PF0-OSC_IN or PF1-OSC_OUT pins, i.e. cannot connect crystal (and one of these is used for input pin for pypass clock).

Page 32: Here we see the same as above. However we discover a unique pin for 32 pin package:

 pin 2, "PC14-OSC32_IN (PC14)", "TIM1_BKIN2", "OSC32_IN, OSC_IN"

 Please note "OSC_IN" as "Additional functions".

Page 35: pin 22 USB_DM and pin 23 USB_DP

(The datasheet was updated yesterday. As far as I have found, no changes except remove of "Prerelease product(s)".)

Now let us jump into the reference manual.

RM0454 Rev 5 Page 126 "External source (HSE bypass)":

"The external clock signal (square, sinus or triangle) with ~40-60 % duty cycle depending on the frequency (refer to the datasheet) must drive the OSC_IN pin, on devices where OSC_IN and OSC_OUT pins are available (see Figure 9)."

Please note "OSC_IN and OSC_OUT"! Why is it a requirement for the OSC_OUT to be available? The signal is put into the OSC_IN pin. It is specified that "The OSC_OUT pin can be used as a GPIO". I cannot understand why it should be a requirement for it to exist in the device for the OSC_IN pin to work. Could it be a typo. When this was written, they just thought about devices with or without both pins. However it now exist a device with one of the pins.

We can turn it around and see it like this: Why should the OSC_IN function exist on pin 2, if it was not possible to use?

PS. I will go for the 48 pin device. Since an external oscillator cost extra and draw much power. When it comes to alternativ 32 pin devices, STM32G0B1KE was proposed. However I also want a stable clock for ADC (so same problem again with HSE). 32 pin devices in G4 family have HSE (great), so maybe STM32G491K. However it have less sram and cost more. So I will go with G0B0.

[Andreas Bolsch]

So this is a bug?!

[MichaelSweden]

In that picture we also can see another bug: The STM32G0B0KETx device have a UFQFPN32 package in STM32CubeMX software. It should be a LQFP32 according to data sheet. Please note the "T" in the device name, it indicate LQFP. According to data sheet all STM32G0B0xE only exist in LQFP packages.

[Viktor POHORELY]

Well, you are right. It would work that way, so could be used. Real external clock source was not considered as option for the platforms targeted by value line products. With external clock source, it should work.

[Viktor POHORELY]

Your point related to the reference manual is valid, document will be fixed (once it is going to be republished).

• External source (HSE bypass)
• In this mode, an external clock source must be provided. It can have a frequency of up to 48 MHz. This mode is selected by setting the HSEBYP and HSEON bits in the Clock control register (RCC_CR). The external clock signal (square, sinus or triangle) with ~40-60 % duty cycle depending on the frequency (refer to the datasheet) must drive the OSC_IN pin, on devices where OSC_IN and OSC_OUT pins are available (see Figure 9). The OSC_OUT pin can be used as a GPIO.
• The OSC_OUT pin can be used as a GPIO or it can be configured as OSC_EN alternate function, to provide an enable signal to external clock synthesizer. It allows stopping the external clock source when the device enters low power modes. Note: For details on pin availability, refer to the pinout section in the corresponding device datasheet. To minimize the consumption, it is recommended to use the square signal.