cancel
Showing results for 
Search instead for 
Did you mean: 

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

RGari
Associate III

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?

 

 

1 ACCEPTED SOLUTION

Accepted Solutions
RGari
Associate III

I found the issue...

I rebuilt the entire Nucleo test project in CubeMX from scratch (deleting all generated source code but keeping the same IOC file), using CubeMX 1.16.0 and H5 HAL 1.3.0 RC1 (the newest version--I had also previously avoided the RC).

Somehow CubeMX had previously missed adding the following line to the clock config:

__HAL_RCC_PLL1_CLKOUT_ENABLE(RCC_PLL1_DIVQ);

(and, Murphy's law, I missed that same bit in the H503 reference manual, too, when trying this manually without the HAL)

The project had been upgraded from older to newer HAL versions and a previous CubeMX version, too.  I suspect this was a problem in one of the previous versions and was fixed, but somehow upgrading did not result in generating this missing line.  Only when I deleted the project entirely (except the IOC file) and re-generated the source code from scratch did this line appear.

I'm not entirely sure which version fixed the issue because it wasn't generating that line until I deleted the source code completely.  But for now, if anyone is having a similar problem, I'm working properly on CubeMX 1.16.0 w/ HAL H5 1.3.0 RC1

 

 

View solution in original post

18 REPLIES 18
AScha.3
Chief II

Is pin speed on mco1-pin set to high ?

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

If you feel a post has answered your question, please click "Accept as Solution".
BarryWhit
Lead II

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.

- If someone's post helped resolve your issue, please thank them by clicking "Accept as Solution".
- Please post an update with details once you've solved your issue. Your experience may help others.
RGari
Associate III

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
Associate III

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
Associate III

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:

clocktree.pngRCC.png

 

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
Lead II

- 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?

- If someone's post helped resolve your issue, please thank them by clicking "Accept as Solution".
- Please post an update with details once you've solved your issue. Your experience may help others.

BarryWhite Wrote:

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

- If someone's post helped resolve your issue, please thank them by clicking "Accept as Solution".
- Please post an update with details once you've solved your issue. Your experience may help others.
RGari
Associate III

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
Lead II

Yeah, I would ask ST at this point.

 

@STTwo-32 , do you have any advice?

- If someone's post helped resolve your issue, please thank them by clicking "Accept as Solution".
- Please post an update with details once you've solved your issue. Your experience may help others.