STM32F4: have MCO2 output (PC9) HSE-clock

[rjmaris]

By default, MCO2 overrides the GPIO-function of PC9. But in order to actually output the clock, the pin must be defined as an output (GPIO-feature). However, when I define a &gpioc 9 in my board .dts file, I end up with a AFRH9 having not it's default value 0 but instead 5. Apparently, doing gpio_pin_configure_dt(&mco2, GPIO_OUTPUT_ACTIVE), this also programs the alternate function.

In short: I need some GPIO action without Alternate Function being set to a GPIO function value.
Or do I need something with KCONFIG & driver code to establish this, as is suggested on this stackoverflow question?

Any help would be appreciated.
If it can be managed, I'd also want to set bits in RCC register CFGR in order to select MCO2 to not output the system clock (which is default). If this is not possible at hardware abstracted level, then soc-specific code is to being added on the start of the main() function, which would also require inclusion of appropriate, vendor-tied (f4) peripheral-header files.
Any hints/doc pointers regarding to this would be appreciated as well.

[rjmaris]

Through commit search in git repository (search "MCO"), I found that MCOx is configured via Kconfig, hence can be activated using e.g. guiconfig. As such I did the configuration.

But actually, no clock can be seen on GPIO output (here: PC9). I used the basic/blinky sample to test it.
I read that clock configuration is done in start up (of course). I could confirm that - in the STM32-case - clock_stm32_ll_common.c is built. However, when I add a printk("configure\n") upon beginning of the stm32_clock_control_init function, nothing is output to the console. Then a test by adding a stm32_clock_control_init(NULL); in blinky main() results in output of printk but still no MCO output...

Any suggestion or pointers to a sample code or appropriate documentation would be appreciated.

[erwango]

You need to add pin configuration in a pinctrl-0 property.
See #31912

[rjmaris]

Well, before you wrote this, I already was on a certain (correct) track. In hal_stm32, I added the following to scripts/genpinctrl/stm32-pinctrl-config.yaml
(corresponding to the alphabetical order)

- name: MCO
  match: "^RCC_MCO_(1|2)$"
  drive: push-pull
  slew-rate: very-high-speed

Then I executed the script and updated the new dts/st files. What I get here is rcc_mco_1_pa8 and rcc_mco_2_pc9.
Shortly after that I got the message of your reply. And I 'simply' added &rcc_mco_2_pc9 with a pinctrl device. Did not work. Then as you suggested there just as part of another pinctrl-0 assignment (with &adc1). Did not work.

Many hours later I believe that Zephyr does not do pinctrl on board dts file 'devices' when those devices are not used at all in the code. Upon a debug session with Eclipse, I found that the for loop in pinctrl_configure_pins() only iterated usart 3 & 6. usart 3 is attached to system console, but usart 6? - according to schematic of nucleo-f429zi, usart 6 is not connected.

Related to your enhancement request in 2021: I agree that the solution with pinmux = <STM32_PINMUX('C', 9, AF0)>; is not elegant (but however: I learnt that this comprises a quick&dirty way to quickly see if something works or not.
@GeorgeCGV suggested to use the chosen keyword to force, but that seems not to have any effect.

Here an excerpt of what I'd mind as a clean solution in a board dts:

&rcc {
	clocks = <&pll>;
	clock-frequency = <DT_FREQ_M(168)>; /* highest value to get a precise USB clock */
	ahb-prescaler = <1>;
	apb1-prescaler = <4>;
	apb2-prescaler = <2>;
	mco {
		pinctrl-0 = <&rcc_mco_2_pc9>;
		status = "okay";
	};
};

The status = "okay" is superfluous - it does not force pinctrl action. And because rcc is not associated at all with 'usage' in runtime - code -, no pinctrl action is ever done with mco (if I guess the underlying mechanism well).

In fact, because of this (hardware, not software), it would also be better to abandon all MCO stuff (clock source) from Kconfig, and instead have all of this in the device tree - according to recommendations from the documentation.

[erwango]

Thanks for this feedback.

I came to the same conclusion that pinctrl-0 prop would finaly fit nicely in rcc node. Usingit in a mco node as you propose make it clean.
It also allows to instanciate the code when 2 mcos are available.
We can get STM32 clock control drivers performing the pinctrl api call in stm32_clock_control_mco_init() if pinctrl node is present.
Once done, configuring the clock source would be an easy addition and would allow to fully remove Kconfig.

[rjmaris]

A pinctrl api call from rcc is exactly that what would be the logical choice. Then a devicetree node would strictly not be necessary, but should still be required because that indicates to users that the pin cannot be used as gpio. Moreover, when the configuration options are transferred from Kconfig to devicetree, mandatoriness of devicetree usage is necessarily given.

[joerchan]

I was also trying to figure out how to correctly configure the MCO pin.

I think a sample is wise to have some working code to show, I've added one here:
#76292

I used an unrelated node to assign the pin, the sample could be updated with an improved method once an MCO node has been added to the STM boards.

[rjmaris]

@erwango : could you please consider whether closing this issue is appropriate? Anyway, this is a reminder for me to check the status.
After having updated my local git repository from upstream I don't see changes related to getting mco control no longer based by KCONFIG and instead by means of mco1&2 nodes. Your suggested modification of stm32_clock_control_mco_init() (in drivers/clock_control/clock_stm32_ll_mco.h) is not carried out until now.
FYI: My (still used) workaround is in my board file is as follows:

&usart6 {                    /* mco2 pinctrl temporarily within usart 6 */
	pinctrl-0 = <&usart6_tx_pc6 &usart6_rx_pc7 &rcc_mco_2_pc9>;
	/* pc6 and pc7 are not connected for other uses, hence future capability */
	pinctrl-names = "default";
	current-speed = <115200>;
	status = "okay";
};

I had put the mco pin control in another node.
Alas, this requires a change in an externally included STM32 repository, in modules/hal/stm32 - as described here: #58443 (reply in thread)

[erwango]

@rjmaris Note that the hal changes have been integrated (see zephyrproject-rtos/hal_stm32#195). Agree that issue is not complete but there is already an issue open to track the progress, I'd prefer avoiding multiple discussions thread in the same topic