2024-08-31 05:54 PM
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?
Solved! Go to Solution.
2024-09-02 02:21 AM - edited 2024-09-02 02:22 AM
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.)
2024-09-02 04:13 AM - edited 2024-09-02 04:13 AM
Also worthwhile testing MCO2 on the nucleo
2024-09-02 04:21 AM
Hello @RGari ,
Could you please attach your ioc file so I could test the behavior by tomorrow?
Thank you
2024-09-02 07:50 AM
Read out and check/post the relevant RCC registers content.
JW
2024-09-02 09:23 AM
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...
2024-09-02 12:40 PM
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
2024-09-02 06:37 PM - edited 2024-09-02 07:05 PM
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?
2024-09-02 10:15 PM
Just don't ever trust CubeMX & HAL...
2024-09-03 12:09 AM
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