Half real baud rate vs. configured

[SKled.1]

I used STM32CubeIDE on a Nucleo-L073RZ board to, using LL for everything, configure USART1 to

• 19200 bauds,
• 8N1,
• oversampling=16x,
• In IOC file Clock Configuration,
  • "USART1 Source Mux" shows 32MHz, from PCLK2,
  • which is the same as all bus clocks & sysclock
  • The input comes from HSE, which is, from that I saw, the tapped 8MHz from the on-board debugger MCU, which used to work for me in the past.

So there seems nothing wrong with the general clock setup.
Yet, on the oscilloscope, I see that the bit width of double the width of 19200, i.e. I am getting 1/2 the expected baudrate.

EDIT: I configured PA8 MCO pin to SYSCLK with DIV1, and lo and behold, it shows 16 MHz on the oscilloscope, instead of expected 32. So that explains the baud rate: but everything in Cube is showing me 32 MHz...
EDIT #2: Aha! I put now HSE on MCO, and it's 4 MHz! That comes from the STLink on this NUCLEO board. I could swear it used to give 8 MHz, and it has a 8MHz crystal on it.
BUT I very recently let CubeIDE update the firmware of this ST-Link.
Is this a bug of this new ST-Link firmware, that it only outputs 4 MHz to the other MCU on this devboard? (IIRC it's the MCO of the on-board ST-Link that's being used for this, so a divider in the firmware might be set wrong)

Any ideas what might cause this?

[waclawek.jan]

Is it 4MHz on the STLink's MCO pin, too?

JW

[SKled.1]

Good idea. Measuring @ C10 in the ST-Link schematic from UM1724 Rev13, it shows indeed 8 MHz.
Things work as expected on the USART after I entered 4 instead of 8 MHz as INput Frequency in CubeIDE Clock Configuration, though. And my target's MCO source divider was set to DIV1 (I used all the readily defined LL macros etc).
So what the heck is going on here...

[SKled.1]

Not sure what you are talking about.
"on the oscilloscope, I see that the bit width of double the width of 19200, i.e. I am getting 1/2 the expected baudrate"
seems pretty clear to me, save for the grammatical error.

[waclawek.jan]

> nice

Thanks. I'll add it to the list (which is already too long...).

> any ideas what could be happening here?

I've tried to experiment with external clock input in the past without bypass, and I experienced no problems. However, that was on a particular STM32 ('F4 or 'F0 I don't remember), and the fact is, that the HSE circuitry differs vastly between STM32 families (as withessed by AN2867). Also the fact that I didn't have problems does not mean that this is the proper thing to do. The HSE when fed from oscillator but not set as BYPASS may for example work "properly" only in some frequency region, or may be picky about the particular shape of clock signal.

So, no, no idea; and I am also not sure if it is worth further investigation. This is one of those things which are "simply don't do it, even if it seems to work, the consequences may be surprising and may bite".

JW