STM32F427 is sometimes running slow after boot

[Anttu Koski]

I have an issue with STM32F427 where after doing reset for MCU in some cases the MCU is running at about half the speed after reset. All peripheral clock seem to be running at normal speed, but the MCU is just running at half the speed. All register values are identical to case where it runs at normal speed. Doing a full power cycle reset fixes the issue always.

Any ideas what could slow down the MCU? Can I trust that the RCC register values show the clocks that are in use?

[waclawek.jan]

> MCU is just running at half the speed

How do you know?

JW

[TDK]

Given that peripherals are clocked off of the system clock, I don't see how this would be possible. Perhaps you can explain more why you think it's the case.

Yes the RCC registers can be trusted.

[Anttu Koski]

There's for example some LEDs blinking that blink at half speed. They rely on SysTick. Also there's some instrumentation for checking how much time the code takes to run, and it's roughly doubled. Also some functionality starts giving overflows, because the processing cannot handle everything in time.

[Anttu Koski]

I mean RCC registers (and all others) are identical in cases where MCU is running normally or slowly. I'm just wondering could for example the bit showing that RCC_BDCR->HSERDY or other bits there show wrong status after reset..

The errata also mentions quite vaguely about something about delay needed after clock enabling, but I don't know how that's supposed to affect.

https://www.st.com/resource/en/errata_sheet/dm00068628-stm32f427437-and-stm32f429439-line-limitations-stmicroelectronics.pdf

2.2.6 Delay after an RCC peripheral clock enabling

[waclawek.jan]

> There's for example some LEDs blinking that blink at half speed. They rely on SysTick.

> Also there's some instrumentation for checking how much time the code takes to run, and it's roughly doubled.

> Also some functionality starts giving overflows, because the processing cannot handle everything in time.

May be also processor exhaustion due to excessive interrupts, or any other resource starvation.

Try to remove parts of your program, one by one, to find out which one causes this effect.

JW

[Anttu Koski]

Unfortunately it's quite difficult to remove most of the parts of code. I've done it for some parts and had no luck.

I guess there is no easy way of instrumenting how often interrupts happen... Going through all interrupts guessing what might help is just going to take immense amount of effort and the fault might not even be there.

I don't think it's resource starvation, because it happens in all parts of the program that run very different code.

[TDK]

> I guess there is no easy way of instrumenting how often interrupts happen

Typically this is done by flipping a bit high during the ISR, and returning it low when it exits. This lets you view it very easily on a scope.

[Anttu Koski]

Sure, it's easy for one. But when you have all the interrupts on the MCU to check...

[TDK]

> But when you have all the interrupts on the MCU to check...

Then what? Two lines of code per relevant interrupt seems a very doable task to me.

You have to realize that saying the cpu slows down and yet all peripherals retain their same speed is a pretty wild claim. That's just not supported by how the architecture is built.