No HSE output using MCO1

[Stratosstratos]

Hello,

I am trying to output the HSE to a GPIO PA8.

I want to do it from scratch and have added this code to the HID example from ST.

 

RCC->AHB1ENR |= RCC_AHB1ENR_GPIOAEN; // Enable GPIOA clock
		GPIOA->MODER &= ~GPIO_MODER_MODE8; // Clear the mode bits for PA8
		GPIOA->MODER |= GPIO_MODER_MODE8_1; // Set PA8 as alternate function
		GPIOA->AFR[1] &= ~GPIO_AFRH_AFSEL8; // Clear AF selection for PA8
		GPIOA->AFR[1] |= (0x00 << GPIO_AFRH_AFSEL8_Pos); // Set PA8 to AF0 (MCO1)
		RCC->CFGR &= ~RCC_CFGR_MCO1; // Clear the MCO1 source

		//Choose Source
		RCC->CFGR |= RCC_CFGR_MCO1_0; // Select HSE as MCO1 source

		RCC->CFGR &= ~RCC_CFGR_MCO1PRE; // Clear the MCO1 prescaler bits
		RCC->CFGR |= RCC_CFGR_MCO1PRE; 		 // Set MCO1PRE bits to 010 for division by 5

 

 The code works only for HSI and PLL ( confirmed with an oscilloscope).
What could be causing HSE not to be outputted ?
I tried with and without the prescaler enabled.

I am also attaching the whole project file.

[Andrew Neil]

---

@Stratosstratos wrote:

I want to do it from scratch and have added this code to the HID example from ST..

---

Have you tried it with a simpler example; eg, just a "blinky"?

Even though you want to do it "from scratch" in the end, try it using CubeMX first - if that works, then look into what CubeMX does that your code is missing ...

[waclawek.jan]

Which STM32?

> What could be causing HSE not to be outputted ?

HSE not running, for example.

JW

[Stratosstratos]

Board : nucleo-f439zi

Microcontroller :STM32F439ZITbu (RM : https://www.st.com/resource/en/reference_manual/rm0090-stm32f405415-stm32f407417-stm32f427437-and-stm32f429439-advanced-armbased-32bit-mcus-stmicroelectronics.pdf)

>HSE not running, for example.
Will search it.

[######]

Apologies if I'm mistaken, however...

Are you sure this line selects the HSE?

RCC->CFGR |= RCC_CFGR_MCO1_0; // Select HSE as MCO1 source

When I had a quick look of the RM00090 page 168 I wonder if you might be selecting the LSE in error? Which might not be connected?

00: HSI clock selected
01: LSE oscillator selected
10: HSE oscillator clock selected
11: PLL clock selected

Perhaps try:

RCC_CFGR_MC01_1 instead of RCC_CFGR_MC01_0?

Best of luck with it.

[Stratosstratos]

You seem to be right since i do measure RCC_CFGR_MC01_1 to be 8Mhz with the oscilloscope.

[Andrew Neil]

Doesn't the F4 HAL provide a meaningful name like RCC_CFGR_MCO_HSE to avoid that kind of mistake?

[waclawek.jan]

It would be a mistake to rely on Cube/HAL constants - they are defined haphazardly, with no system in them, and also including Cube/HAL headers would bring in a whole bunch of other unwanted symbols, often just renaming the existing ones.

The proper way to do this is to define symbols meaningfully naming states of multi-bit bitfields, directly in the CMSIS-mandated headers, or in sub-headers containing only this kind of symbols, to be included together with those CMSIS-mandated headers.

Incidentally, the CMSIS-mandated headers *do* define *some* (very few) of such symbols, for historical reasons, mainly for RCC (but not for RCC_CFGR.MCO) - for example RCC_CFGR_SW_HSI/RCC_CFGR_SW_HSE/RCC_CFGR_SW_PLL; however, these are wrong. I personally would recommend to use a double-underscore to separate the value from the field's name (RCC_CFGR_SW__HSI); but what's much more important, these values should *not* be the shifted values as they are now but be the values of the field itself, for consistency with such bitfields that are repeated at various shift positions (e.g. TIM_CCMRx_OCxM) and also so that they exactly match the values given in the description of given bitfield in the RM. In code they then ought to be shifted to the left by the related xxx_Pos symbol.

I am preaching this here for years, just to be completely ignored by ST.

JW