stm32f030cc clock exception

[Lyu.1]

platform: stm32f030cc

SDK: STM32F0xx_StdPeriph_Driver (V1.5.0)

Startup file: startup_stm32f030xc.s

Clock configuration: Since the HSE external pins are made as ordinary GPIO ports, HSI is used as the system clock source. The configuration is as follows:

static void SetSysClock_test(void)
{
  __IO uint32_t StartUpCounter = 0, HSEStatus = 0;
  
  /* SYSCLK, HCLK, PCLK configuration ----------------------------------------*/
    RCC->CFGR &= (uint32_t)((uint32_t)~(RCC_CFGR_PLLSRC | RCC_CFGR_PLLXTPRE |RCC_CFGR_HPRE|RCC_CFGR_SW| RCC_CFGR_PLLMULL));
    RCC->CFGR |= (uint32_t)(RCC_CFGR_PLLSRC_HSI_DIV2 | RCC_CFGR_HPRE_DIV1|RCC_CFGR_SW_PLL | RCC_CFGR_PLLMULL12);
    RCC->CR |= ((uint32_t)RCC_CR_PLLON);
    /* Wait till PLL is ready */ 
    while((RCC->CR & RCC_CR_HSIRDY) == 0)
    {
    }
     /* Wait till PLL is ready */
    while((RCC->CR & RCC_CR_PLLRDY) == 0)
    {
    }
    
    
  /* Disable HSE */    
  RCC->CR &= ~((uint32_t)RCC_CR_HSEON);
  
   return;
}

phenomenon:Most of the time the program triggers hardfault in __main, there is a very small probability to enter main (), I suspect it is overclocking (96M?).. So I changed RCC_CFGR_PLLMULL12 to RCC_CFGR_PLLMULL6 ,but it appeared as follows:

phenomenon:

1. OS_CPU_SysTickInit (48000000ul / OS_TICKS_PER_SEC);(#Define OS_TICKS_PER_SEC 5000u) ，I found that the systick interrupt is triggered once for 400us.

2. When I set SPI_InitStructure.SPI_BaudRatePrescaler = SPI_BaudRatePrescaler_2 of SPI1, I found that the clock of spi1 is only 12M From this, it is determined that the system clock is only 24M.

What is the reason for this?

thank you very much!

[berendi]

The code would result in a 48 MHz clock. 8/2*12 = 48.

You should set FLASH_ACR_LATENCY to 1 before to avoid the frequent flash read problems you have experienced.

HSIRDY should be checked before configuring the PLL to use it, but it's probably running since reset anyway.

[Lyu.1]

Hi,Master:

Thank you very much for your authoritative answer. I still have a few questions and I need further help:

Question 1:

In the clock tree in the screenshot I took earlier, HSI is directly used as PLLSRC. There is no frequency divider in the middle of this.I didn't understand how this frequency divider 2 came out?

Question 2:

The LATENCY of the FLASH_ACR register you mentioned, I refer to the description in the manual, and I don't really understand its meaning. Is it necessary to set it to 1 when the system clock is above 24M, what does this value mean? I used to use stm32f030c8 as the default value (0), But there was no problem.

Question 3:

Your answer mentioned: "HSIRDY should be checked before configuring the PLL to use it, but it's probably running since reset anyway."

Should it be like this?

    /* Wait till HSI is ready */ 
    while((RCC->CR & RCC_CR_HSIRDY) == 0)
    {
    }
    RCC->CR |= ((uint32_t)RCC_CR_PLLON);
     /* Wait till PLL is ready */
    while((RCC->CR & RCC_CR_PLLRDY) == 0)
    {
    }

thank you very much!

[Lyu.1]

Hi,Master:

about Question 3:​

I'm very sorry about the third question, I have carefully observed by comparing the library function SetSysClock, I have understood.

Questions 1 and 2 may also need your guidance.

[berendi]

Now I am just as confused as you.

The description of the RCC_CFGR register in the reference manual says,

Bit 16 PLLSRC: PLL entry clock source

Set and cleared by software to select PLL clock source. This bit can be written only when PLL

is disabled.

0: HSI/2 selected as PLL input clock

1: HSE/PREDIV selected as PLL input clock

that's why I have assumed that the frequency is divided by 2.

Can you post the CR, CFGR and CFGR2 register values before/after configuring the clock?

[waclawek.jan]

Did that code compile at all?

There are no RCC_CFGR_PLLMULL / RCC_CFGR_PLLMULL12 symbols in the device header (there are RCC_CFGR_PLLMUL / RCC_CFGR_PLLMUL12 though)

JW

[waclawek.jan]

Q1: As berendi said, if you select PLLSRC=0, input to PLL is HSI/2 - the PREDIV in the diagram in your screenshot is forced to 2.

Q2: The internal FLASH is too slow to run at 48MHz, so accesses to it have to be slowed down by the FLASH controller, that's where the latency setting comes into play:

 FLASH->ACR = (1 << FLASH_ACR_LATENCY_Pos) | FLASH_ACR_PRFTBE; // 1 cycle latency, + switch on prefetch

JW

[berendi]

> the PREDIV in the diagram in your screenshot is forced to 2.

My problem is that it is somewhat ambiguously documented.

• There are two versions of the clock tree diagrams both in the datasheet and in the reference manual, one for STM32F030xC without the /2 divider (shown above), and one for STM32F030x4/x6/x8, which shows a /2 divider on the path from HSI to the PLL input multiplexer.
• No mention of forcing PREDIV or RCC_CFGR_PLLXTPRE (which would have the same effect) in the RM. What makes you think that it is forced to 2?
• Setting PLLMUL to 12 in CubeMX results in 96 MHz system clock (and a red warning) on STM32F030CC, but 48 MHz on STM32F030F4.

but

• The documentation of RCC_CFGR_PLLSRC contains HSI/2 unconditionally
• Results with SysTick and SPI above support the presence of the /2 divisor

[waclawek.jan · Accepted solution]

 > My problem is that it is somewhat ambiguously documented.

Yes, that's the problem of all of us, we all know the ST documentation is lacking and ST does not care.

So, some guesswork is allowed, I suppose.

Unlike other STM32 families, the 'F0 family is very uniform, in fact a single RM0091 covers it all quite well. (They have some small differences in pinout even where peripherals are shared across the whole family, but this is treated with separate datasheets for the different non-zero-ending family members.)

Except some modules not being present on lower-end models, there are also other minor differences, though, and in RCC, in this very particular issue we discuss here, 'F051 and 'F031 have only one bit PLLSRC field in RCC_CFGR - the 'F042/072/091 have two bits. There are two drawings for the clock tree in RM0091, reflecting this.

ST then generated the "stripped-down" 'F050 and 'F030 versions and created a separate RM for them (they are very similar indeed) probably to partially cover up the fact that the peripherals which are "not present" in the 'Fxx0 are in fact there just untested. But then later decided to rename 'F050 to 'F030 too, distinguishing the two only by the memory-size-suffix; and added into the 'F030 group also the stripped-down 'F091as 'F030xC (stripped-down 'F042 and 'F072 are collectively called 'F070 and they have a separate RM). So that's why there are confusing clock tree diagrams and descriptions. This created also the mess in the pintable of 'F030 DS, as now all three different dies are in the same 'F030 DS.

So, long story short, with the 'F030/'F070, you may be better off reading RM0091 and the datasheets of the respective 'F0x1/'F0x2 chips, while remembering that some of the peripherals are "not there" and the parameters (temperature range etc.) are reduced.

JW

[Lyu.1]

Thank you very much for your wonderful and experienced answers.