cancel
Showing results for 
Search instead for 
Did you mean: 

Systick overspeed?

Ken CK
Associate II
Posted on February 05, 2018 at 00:32

I'm using an STM32F429ZI Nucleo-144 board with CubeMX, enabled FreeRTOS, LWIP, USARTs, IWDG, RTC. The HSE clock source is the on-panel ST-Link 8MHz, the LSE clock source is the on-board 32.768 kHz crystal oscillator.

Since I have recently upgraded to latest cube package version (upgraded FreeRTOS, HAL, CMSIS, Cube libs) I realized that the time base of the panel just got speedy. If I use it to calculate time (and not the RTC), I experience about a 20% overspeed.

I tried using bothe the Systick and Timer1 to provide the timebase source, with the same outcome.

Additional information is that I power the board from external 12V.

Any ideas why this symptoms may come up?

Here are the clock configs from Cube:

0690X00000609T4QAI.png

#systick-timer #stm32-f4 #stme32-cube
16 REPLIES 16
Posted on February 05, 2018 at 17:09

As Clive said, use MCO to push the clock out for monitoring

+1

Also, read out and post the content of relevant RCC and SYSTICK (STK) registers.

JW

T J
Lead
Posted on February 05, 2018 at 22:31

He is building a time machine

Posted on February 05, 2018 at 22:57

It seems that you have provided a lot of information, just not what others have asked for. 'Pretty sure' isn't going to be helpful in getting your code debugged.

Given that you have incorrect timing over two different and independent mechanisms, logic would dictate that you want to take a fresh look at your diagnosis.

Posted on February 07, 2018 at 12:42

I have configured the MCO with prescaler to output 2 MHz clocked from the system clock, also measured with a scope and found it to be precisely at the 2 MHz.

Also captured RCC register contents (see screenshot).

An additional finding: when the board starts up it measures time correctly up until about 1-2 hours. Then something goes wrong and the timing gets speedy. I have not yet been able to measrure MCO when the problem occurs, once I've done that I will publish my findings. Also I will start logging out the contents of registers to identify if something is changing after this 1-2 hours period.

Also one more info - the core clock is set to 180 MHz (power scale 1, overdrive enabled). Not sure if this is important or not.

0690X00000609dqQAA.png
Posted on February 07, 2018 at 12:55

And the Systick registers content?

Of course, both are interesting only when the problem occurs.

JW

PS What debugger is this?

Posted on February 07, 2018 at 13:02

Also, can't there be some mistake/error in the process how do you observe the 'speedup'?

You wrote:

Systick is configured to run at 1kHZ rate. Based on this systick I do a single uptime calculation (basically storing elapsed seconds) to measure how long the board has been running since its latest (re)start.

it measures time correctly up until about 1-2 hours.

Arithmetic overflows come into mind.

Can you please simply increment a 32-bit variable in the systick interrupt, and observe that one directly?

JW

Posted on February 07, 2018 at 14:07

Using Eclipse with SystemWorkbench, GCC toolset.

Yes, I was also thinking about a possible overflow. However this is not just the systick, as I mentioned the same happens with the RTC running on an independent clock. However I will still do what you suggested.

I'm pretty sure finally this will be a banal issue.