Systick overspeed?

[Ken CK]

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:

#systick-timer #stm32-f4 #stme32-cube

[henry.dick]

Posted on February 05, 2018 at 00:54

'

Any ideas why this symptoms may come up?'

you calculated it wrong? since you didn't say, it is one of the possibilities. hard to tell for sure.

what is your SystemCoreClock?

[Ken CK]

Posted on February 05, 2018 at 06:54

To be honest I have not done any calculation, I have used CubeMX to configure the clocks. The system core clock is 180 MHz. And as I mentioned these symptoms raised since I have upgraded HAL, CMSIS, etc. libraries.

[henry.dick]

Posted on February 05, 2018 at 12:16

'

To be honest I have not done any calculation...'

and here lies the problem: you keep saying that systick is advancing too fast but vs. what? and how do you know it is advancing too fast?

if you don't help other people help you by laying down some facts, keeping saying it is too fast doesn't really help pin-point your problem(s) here.

[Tesla DeLorean]

Posted on February 05, 2018 at 01:16

Recommend outputting LSE via MCO (PA8) and then scoping it.

Internally you can use TIM5 to benchmark the clock against HSE or PLL, etc

[Ken CK]

Posted on February 05, 2018 at 06:56

I will check it this way, however I'm pretty sure there is a clock mismatch since the library upgrades. So this way I can prove it 100%, however still unsure about the reasons.

[S.Ma]

Posted on February 05, 2018 at 05:07

As Clive said, use MCO to push the clock out for monitoring (with prescale if too high), if MCO is used, then

toggle an LED on and off every second and measure 10 blinks to check out the 20% clock mismatch.

[waclawek.jan]

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

[Ken CK]

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.

[waclawek.jan]

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?

[T J]

Posted on February 05, 2018 at 22:31

He is building a time machine