STM32H503 MCO1 pin from PLL1Q generates no output; other sources work correctly

[RGari]

I saw at least one person elsewhere mention this (but got no answers).

On the STM32H503 (LQFP48 pin package)...

This configuration:

HAL_RCC_MCOConfig(RCC_MCO1, RCC_MCO1SOURCE_HSE, RCC_MCODIV_5);

Produces no output on the MCO1 pin

but changing it to this:

HAL_RCC_MCOConfig(RCC_MCO1, RCC_MCO1SOURCE_HSI48, RCC_MCODIV_1);

generates an output (albeit, not terribly accurate, which is expected from that source).

In fact, I tried every other source setting and they all work except PLL1Q.

PLL1 is configured as:

HSE=24Mhz crystal

M= /12, N=x250, Q = /2, and MCO divider = /5  So output should be 50MHz

I confirmed that the HAL is setting the register correctly (RCC_CFGR -> MCO1SEL == 0x011) via SWD.

I see nothing in the Errata on this---is there a silicon bug here?

[AScha.3]

Is pin speed on mco1-pin set to high ?

( or try to lower output speed, MCO divider = /10 )

[BarryWhit]

> HAL_RCC_MCOConfig(RCC_MCO1, RCC_MCO1SOURCE_HSE, RCC_MCODIV_5);

> Produces no output on the MCO1 pin

> [...]

> In fact, I tried every other source setting and they all work except PLL1Q.

Which is it? all sources work except PLL1Q, or both HSE and PLL1Q do not work?

1. Did you verify that that the PLL is configured and enabled properly - can you use it as HCLK and see code running?

2. if you're manually writing HAL code, did you try replicating your desired config with CubeMX and testing the generated code? perhaps you forgot a step in your hand-written code.

3. What is the source clock for the PLL? if it's HSE, and HSE isn't functioning properly then of course running it through a PLL out to MCO won't work.

4.Does PLL1Q work as an MCO source if you feed the PLL from another clock source?

5. The examples given use different divisors. That means you're changing two things at once, both source and divisor. Try first by setting the divisor to max (it's easiest to work with the lowest freq out possible for debugging) and repeat the test for all sources.

[RGari]

Speed set to VERY_HIGH.

HSE works.  HSI48 works.  HSI works.  PLL1Q does not.  PLL1 is driving other things on the chip, so I know the PLL itself is working.

(did not test LSE because I don't have a LSE crystal connected in this design). 

I also reproduced this same issue both on a board of our own design (far from the first STM32-based board I've designed) and also on the nucleo-h503rb board.  Same results on all.

[RGari]

Code was written by CubeMX (not manually written).  Using the HAL.  I manually verified that the SFR's are set properly, too, using CubeIDE with SWD reading the actual registers (the SFR tab).

I have been developing with STM32 chips for many years so I am very familiar with the clock trees involved.

I have also tried a few different divisors--no difference.

[RGari]

I anyone would like to reproduce it, it is very easy to reproduce.

Build a project in CubeMX for the Nucleo-h503RB board.  

NOTE: You have to manually set the pin drive strength to VERY_HIGH because CubeMX will default it to LOW.

Configure the clock tree as follows:

You will get no output on MCO1 (PA8 which is pin D7 on the Arduino connector on that Nucleo board).

Now, re-test, changing the MCO1 clock source to any of the other choices and you will get the expected output.  Try changing to using different dividers and same results--no output with PLL1 but works with the others.  (I tried all the way to /15 which is the max for MCO1).

[BarryWhit]

- The STM32H503 in LQPF48 packages does not have MCO2 available, only MCO1. Why does the screenshot for the RCC peripheral show MCO2 as being available?

- which version of CubeIDE and MCU firmware package are you using?

[BarryWhit]

BarryWhite Wrote:

> 4.Does PLL1Q work as an MCO source if you feed the PLL from another clock source?

[RGari]

The "simple" repro I did above (screenshots) was with the Nucleo board, which does NOT have the LQFP48 package (so it does have the MCO2 pin).  I did that because it's easier for people in the forum to repro with that than with an LQFP48 which has no Nucleo board available.  I confirmed that the same problem exists with both chip packages.

I have the CPU being driven by PLL1 so I know that the PLL is operating (or it would lock up) 

I'm using CubeMX 6.12.0 with H5 HAL 1.2.0 (both of these are the most current available).  I also tried H5 HAL 1.1.1 (the previous version) and had the same results.

Just to rule out the HAL and CubeMX entirely, I also tried the same test by manually setting all necessary registers (no HAL) and the results are the same.  And I confirmed again, that even when I did everything manually, but driving MCO1 from the other sources instead of PLL1, it worked fine.  

Using the Nucleo board (because it's more handy at the moment) I just tested using HSI as the PLL1 source (with PLL1M set to 40 and keeping everything else the same so the CPU clock stays within range).  Still no output on MCO1 if it is sourced from PLL1Q.

[BarryWhit]

Yeah, I would ask ST at this point.

@STTwo-32 , do you have any advice?