cancel
Showing results for 
Search instead for 
Did you mean: 

Trouble configuring the system clock for an STM32F303K8T6 for speeds higher than 16Mhz (using CubeMX and CubeIDE)

AHatt.1
Associate II

Hardware:

My board is a custom board that has an STM32F303K8T6. It has an external 8Mhz crystal as well as a ferrite choke between VDDA and VDD, and other passive capacitors.

Situation:

I am trying to configure the system clock for 72mhz using Cube MX(6.2.1) and the Cube IDE (1.5.0). First, my test program (blinking LEDs, and printing/receiving serial commands) runs fine when the input to the System Clock Mux is simply the internal (HSI) or external (HSE) clock with no PLL multiplier. It also runs fine with any combination of PLL multiplication and dividing as long as the output of the System Clock Mux is less than or equal to 16mhz (example described below).

Problem:

When I attempt to use a higher PLL multiplier (for example to get my desired clock configuration that's attached), my program seems to crash.

After using the debugger, I see my program enters the SystemClock_Config function, makes it to HAL_RCC_OscConfig, and then the debugger loses communication during the PLL Configuration at the macro" __HAL_RCC_PLL_ENABLE()". Attached are screenshots of these areas of code as well.

I'm not sure how to debug next. I've tried using the internal and external clocks with varying multipliers and have been unable to get anything above 16mhz at the System Clock to work. Ex: Input HSE @8mhz /8 before the PLL MUX with a PLL multiplier of 16x = 16Mhz SYSCLK works fine but I cannot reach my desired clock speed.

Thanks!

11 REPLIES 11
TDK
Guru

You might try removing the ferrite bead and connecting VDD and VDDA directly. Verify all VSS/VSSA pins are grounded. Verify all VDD pins are properly soldered. Maybe set flash wait states before increasing clock.

Include your schematic if you can.

There are a few other questions like this, all custom boards, which make me believe it's a common hardware mistake.

https://community.st.com/s/question/0D53W00000XHVM8/pllrdy-flag-wont-set

https://community.st.com/s/question/0D50X0000Bh7wPU/why-is-target-is-not-responding-after-main-pll-is-enabled

https://community.st.com/s/question/0D50X00009XkWCjSAN/stm32f042f4p6-keeps-resetting-iwdg-

If you feel a post has answered your question, please click "Accept as Solution".
AHatt.1
Associate II

I'll verify the hardware next but attached is a picture of the relevant part of the schematic.

Thanks for the links and recommendations!

I verified that both VDD pins are connected to 3v3 and both VSS pins are grounded. I then tried removing the external crystal and tried to change the clock speed based on only the internal clock. Still no luck. I then also removed the ferrite choke and connected VDD/VDDA with a wire with the same result.

As for the flash wait states, that seems to come into play in HAL_RCC_CLockConfig and my debugger loses connection before that (making me think something is going wrong before that?)

Any more advice is much appreciated.

Thanks!

Schematic seems fine, other than CHOKE1 which I'm a little suspicious of.

If you feel a post has answered your question, please click "Accept as Solution".

Trying your code on a "known good" board such as Nucleo or Disco would reveal, whether the problem is in your hardware or elsewhere.

Did you try some "intermediate" PLL output frequency, e.g. 24MHz? Also, try writing your own code setting clocks/FLASH-waitstate, rather than relying on Cube's overcomplicated stuff.

JW

Piranha
Chief II

If putting a choke for VDDA/VREF+ supply, I would follow the AN4206 and besides the 100/10nF decoupling capacitor also put a bulk 1uF capacitor after the choke. Though, as you already tried removing the choke, most likely that is not the issue in this case.

Either you have to debug every single line of code and register bit that CubeMX generated bloatware modifies, or better follow the Jan's advice and write your own clean and correct code. The number of lines will be the same or even less than you have in SystemClock_Config() function now.

I had a nucleo on order and it just arrived today which did help find a workaround but not a concrete reason for this bug I am experiencing.

TLDR: I got everything to work at the higher sysclock rate by initializing Usart2 even though I'm not using it. This is working with my desired HSE->PLL Multiplier.

The problem appears to be related to usart configuration perhaps?

My board uses usart1 which I initialized and configured using Cube. This worked fine until I tried bumping up the clock like described in the op. I then tried to use the same code, on the nucleo f303 but because nucleo uses Usart2 connected to its usb port I changed my code accordingly (only initializing/using usart2). This worked fine on the nucleo! I then tried to upload the same code to my board (since usart2 is unused/unconnected on my board) and this time the code seemed to run since the led was blinking again.

I then left usart2 as initialized but unused and added in the Usart1 configuration, and everything continued to work on my board. I tried to remove the usart2 initialization and I was back in the same state as the op.

I created two separate projects (one as a Nucleo F303k8 and one as a generic F303k8) and both had the same behavior (only working when Usart2 is initialized)

If anyone has any idea why initializing PA2 and PA15 (they are the nucleo's default usb tx/rx pins) as usart2s fixes my problem I would love to know but for the time being I am fine with this workaround.

Attached are some additional pictures of my current working Pinout View and Clock Configuration in CubeMX.

It appears I can't attach more than one image in a reply so here's the clock config