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?

 

 

18 REPLIES 18

Just try a last check: set PLL1Q to lower frequ, like 50M . + MCO divider /5 or /10 , so 5 or 10M should come out.

-- to see, that this is not a frequency related problem, but a general bug. 

(I cannot try, because i dont have a H503 ; on H563 PLL1Q -> MCO1 is working - i tried.)

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

Also worthwhile testing MCO2 on the nucleo

- 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.
SofLit
ST Employee

Hello @RGari ,

Could you please attach your ioc file so I could test the behavior by tomorrow?

Thank you

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

Read out and check/post the relevant RCC registers content.

JW

LCE
Principal

Same idea as @AScha.3 above:

on some STM32 the MCO frequency is limited, maybe that starts with your type at the MCO MUX.

Writing that: 250 MHz is quite high for almost anything...

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

 

 

BarryWhit
Lead II

The final 1.3.0 was released on July 2nd, two months ago. Version 1.3.0 is also what shows up on the ST download site. Where did you get an RC version from?

- 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.
LCE
Principal

Just don't ever trust CubeMX & HAL...

Thanks for coming back with the solution. Please click on "Accept as solution" in that post so that the thread is marked as solved.

JW