STM32L Discovery, How to output HSI with MCO

[ota-s]

Hello.I am currently developing with STM32L Discovery.

In preparation for development, I tried to output using the MCO in order to know the exact frequency of the HSI of the evaluation board used.

By operating MCOSEL in the RCC-> CFGR register, MSI and LSI could be known, but HSI and the PLL from which HSI originated were not output for some reason.

How can HSI and PLL MCO output be possible?

Please lend me your help.

[waclawek.jan]

> HSI and the PLL from which HSI originated were not output for some reason.

For what reason? How exactly did you "öperate" MCOSEL? Did you try output HSI/PLL divided? Did you set properly GPIO_OSPEEDR of given pin? Is the equipment you are using to observe the pin able to capture high frequencies?

JW

[ota-s]

Hello, I'm glad to giving me a comment.

This time I want to check if the MCO is being output correctly, and there are no complicated settings.

Specifically, you just set the STM32CubeMX to output MCO to the PA8 as shown in the following image.

After that, I changed the MCOSEL bit to 0x2 on the debugger during program execution.

At that time, it has been confirmed that the HSION bit of the RCC-> CR register is 0x1.

By the way, I tried to check HSI in STM32F401RE in the same way, but here I have confirmed a 16MHz pulse.

For this reason, there is no problem with measuring instruments in measuring the target frequency.

Thank you.

[waclawek.jan]

To avoid confusion, are we talking about https://www.st.com/en/evaluation-tools/32l152cdiscovery.html ?

Read out and check the content of related GPIO for that pin (MODER, AFR, maybe also OSPEEDR).

Isn't there some connectivity on that DISCO board for that pin which could prevent it to work as output? Change that pin MODER to GPIO Out and toggle.

JW

[ota-s]

Hello everyone.

I will reorganize my problems.

[HSI and related clock are not output to MCO in STM32L1 series]

• "STM32L-Discovery" and "STM32L1 Value line Discvery"

• The RCC_CFGR MCOSEL [2: 0] bits are as follows.

→ 000: No output

→ 001: SYSCLCK is not output (PLCCLK is selected for SYSCLK)

→ 010: HSI does not output

→ 011: MSI is output

→ 100: No output because HSE is not connected

→ 101: PLLCLK does not output (HSI is selected for PLLCLK)

→ 110: No output because LSI is not enabled

→ 111: No output because LSE is not connected

These can all be explained assuming that HSI is not reflected in the MCO.

On the other hand, programs other than MCO (just toggling other GPIO pins) are operating normally.

Therefore, it seems that HSI is not working.

Please give me wisdom.

Thank you.

[Tesla DeLorean]

Would take a bunch of effort here to reproduce/refute. Does sound to me like you have the processor coming up via MSI, and the HSI isn't started/running for whatever reason.

/**
 * @brief Selects the clock source to output on MCO pin.
 * @note MCO pin should be configured in alternate function mode.
 * @param RCC_MCOx specifies the output direction for the clock source.
 * This parameter can be one of the following values:
 * @arg @ref RCC_MCO1 Clock source to output on MCO1 pin(PA8).
 * @param RCC_MCOSource specifies the clock source to output.
 * This parameter can be one of the following values:
 * @arg @ref RCC_MCO1SOURCE_NOCLOCK No clock selected as MCO clock
 * @arg @ref RCC_MCO1SOURCE_SYSCLK System clock selected as MCO clock
 * @arg @ref RCC_MCO1SOURCE_HSI HSI selected as MCO clock
 * @arg @ref RCC_MCO1SOURCE_HSE HSE selected as MCO clock
 * @arg @ref RCC_MCO1SOURCE_MSI MSI oscillator clock selected as MCO clock
 * @arg @ref RCC_MCO1SOURCE_PLLCLK PLL clock selected as MCO clock
 * @arg @ref RCC_MCO1SOURCE_LSI LSI clock selected as MCO clock
 * @arg @ref RCC_MCO1SOURCE_LSE LSE clock selected as MCO clock
 * @param RCC_MCODiv specifies the MCO DIV.
 * This parameter can be one of the following values:
 * @arg @ref RCC_MCODIV_1 no division applied to MCO clock
 * @arg @ref RCC_MCODIV_2 division by 2 applied to MCO clock
 * @arg @ref RCC_MCODIV_4 division by 4 applied to MCO clock
 * @arg @ref RCC_MCODIV_8 division by 8 applied to MCO clock
 * @arg @ref RCC_MCODIV_16 division by 16 applied to MCO clock
 * @retval None
 */
void HAL_RCC_MCOConfig(uint32_t RCC_MCOx, uint32_t RCC_MCOSource, uint32_t RCC_MCODiv)
{
 GPIO_InitTypeDef gpio;
 
 /* Check the parameters */
 assert_param(IS_RCC_MCO(RCC_MCOx));
 assert_param(IS_RCC_MCODIV(RCC_MCODiv));
 assert_param(IS_RCC_MCO1SOURCE(RCC_MCOSource));
 
 /* Configure the MCO1 pin in alternate function mode */
 gpio.Mode = GPIO_MODE_AF_PP;
 gpio.Speed = GPIO_SPEED_FREQ_HIGH;
 gpio.Pull = GPIO_NOPULL;
 gpio.Pin = MCO1_PIN;
 gpio.Alternate = GPIO_AF0_MCO;
 
 /* MCO1 Clock Enable */
 MCO1_CLK_ENABLE();
 
 HAL_GPIO_Init(MCO1_GPIO_PORT, &gpio);
 
 /* Configure the MCO clock source */
 __HAL_RCC_MCO1_CONFIG(RCC_MCOSource, RCC_MCODiv);
}

[waclawek.jan]

> 001: SYSCLCK is not output (PLCCLK is selected for SYSCLK)

Well then it means your mcu does not run at all.

JW

[ota-s]

Thank you for your advice.

However, I have confirmed that the code related to clock automatically generated using CubeMX is as follows.

void SystemClock_Config(void)
{
 RCC_OscInitTypeDef RCC_OscInitStruct = {0};
 RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};
 
 /** Configure the main internal regulator output voltage 
 */
 __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);
 /** Initializes the CPU, AHB and APB busses clocks 
 */
 RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI;
 RCC_OscInitStruct.HSIState = RCC_HSI_ON;
 RCC_OscInitStruct.HSICalibrationValue = RCC_HSICALIBRATION_DEFAULT;
 RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
 RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSI;
 RCC_OscInitStruct.PLL.PLLMUL = RCC_PLL_MUL6;
 RCC_OscInitStruct.PLL.PLLDIV = RCC_PLL_DIV3;
 if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
 {
 Error_Handler();
 }
 /** Initializes the CPU, AHB and APB busses clocks 
 */
 RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
 |RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;
 RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
 RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
 RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV1;
 RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV1;
 
 if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_1) != HAL_OK)
 {
 Error_Handler();
 }
 HAL_RCC_MCOConfig(RCC_MCO1, RCC_MCO1SOURCE_SYSCLK, RCC_MCODIV_1);
}

I also confirmed that RCC_CR looks like the following image when I check with the debugger.

After all, I think the device is operating on HSI.

What do you think?

Thank you.

[waclawek.jan]

> After all, I think the device is operating on HSI.

I don't know, it's a different register that determines SYSCLK - SW field in RCC_CFGR.

RCC_CFGR also determines what's on MCO.

JW

[Tesla DeLorean]

Personally I'd prefer to see a large scale dump of RCC and related registers via a printf() from the processor's own perspective.

Sort of issue I'd expect to have validation and test coverage, and an errata if broken as described.​ I'd cross-check but it's an old part and I'm not using it.

[ota-s]

The RCC register was output as follows:

name		value		address		bytes
RCC_CR		0x3000303	0x40023800	4
RCC_ICSCR	0x66b06e	0x40023804	4
RCC_CFGR	0x188000f	0x40023808	4
RCC_CIR		0x0		0x4002380c	4
RCC_AHBRSTR	0x0		0x40023810	4
RCC_APB2RSTR	0x0		0x40023814	4
RCC_APB1RSTR	0x0		0x40023818	4
RCC_AHBENR	0x8007		0x4002381c	4
RCC_APB2ENR	0x201		0x40023820	4
RCC_APB1ENR	0x90000000	0x40023824	4
RCC_AHBLPENR	0x101903f	0x40023828	4
RCC_APB2LPENR	0x521d		0x4002382c	4
RCC_APB1LPENR	0xb0e64a37	0x40023830	4
RCC_CSR		0x1c000000	0x40023834	4

Please let me know if I can do anything else.

Thank you.