Question about overclocking STM32F411 in STM32CubeIDE

[CStew.2]

Hello I am working on a one off project that I would like to squeeze every last bit of power out of a STM32F411. I tried to overclock it just by increasing the clock speeds in the clock configuration section of cubeIDE but it always crashes when I try to run it saying there was a "Break at address '0x0' with no debug information available", I was wondering if anyone knew how to fix this or how to overclock properly.

Edit: Just wanted to mention that I am trying to optimise everything it is doing as well, (communicating with sensors at higher speeds, etc).

Many thanks,

Conor Stewart

[TDK]

Increasing clock rate is how you overclock, but there's no guarantee it'll work outside the specified conditions. If it crashes, reduce the clock speed and try again.

If you really need performance, there are better choices out there than the 100 MHz STM32F411.

[CStew.2]

For some reason using cubeIDE as soon as I change the clock speed at all even just 1MHz higher it wont run anything.

I know there are better choices but I'd rather not go down the route of creating a pcb for the project as I dont have any experience with pcb design. Im using the F411 because the development board I have has a small footprint and was easily available and as far as Ive seen there arent many small form factor F405 boards around.

[TDK]

"Won't run anything" is not a useful description. The chip boots up with HSI as the clock so it will at least make it through the startup code until it tries to change the clock. Step through the code, see where and why it fails. Note the HAL might be doing some bounds checking for validity on parameters.

[CStew.2]

Ive now stepped through it to see where it goes wrong and it fails at this part of the code:

If I step through the code one more step then it comes up with this:

The disassembly is shown on the right where as far as I can see its just the movs r0, r0 command continuously and it just crashes after this.

[Tesla DeLorean]

FLASH and ART cache tend to be the critical path, the former can be tuned with extra wait states, the later has limitations on the prefetch path into the core.

[waclawek.jan]

This is not result of one step, this is running through lockup (0xFFFF'FFF9) and then surprisingly some more.

Step-into not step-through, and step in the disasm view to see where it goes astray.

Although, overclocking is simply a no-no. so it's a quite well deserved punishment/early warning.

JW

[CStew.2]

If I step into the asm like I did in the screenshot above it gets to that first line and then if I step again the microcontroller crashes.

[TDK]

If it works correctly with max clock settings, and doesn't work overclocked, isn't that enough of an indication that your settings are too high?

It would be useful to post the clock settings you're trying at least.

From your second screenshot, it's inside a second interrupt handler. Examine the VECTACTIVE bits in SCB->ICSR to see what interrupt it's in.

[waclawek.jan]

> If I step into the asm like I did in the screenshot above it gets to that first line and then if I step again the microcontroller crashes.

Surely you can step in disasm since the reset vector. Find out where that leads to.

JW