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?

[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

[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.

[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.

[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.

[Ken CK]

Posted on February 05, 2018 at 10:04

One additional note - if I'm using RTC, the elapsed time is also in overspeed despite of the independent clocking. I have tested with another board (exactly the same board, same firmware) but using a different power source, and this board is working properly.

So in a sum:

- STM32F429ZI nucleo with external 12v power sourcing: timers are in overspeed

- 

STM32F429ZI nucleo with 5V USB power source through the STLink device: timers are OK

[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.

[Ken CK]

Posted on February 05, 2018 at 12:55

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.

Using this elapsed seconds uptime, I could simply verify that the time itself is precise or highly unprecise.

As I mentioned - before the libraries were updated to latest, the time measurement was enough precise for my needs (less than 1 sec mismatch per 24 hours). After the library upgrades (without any changes made on my side, just CubeMX generated code changes) the mismatch is almost 2 hours in 6 hours period. That is pretty significant.

[henry.dick]

Posted on February 05, 2018 at 15:14

Debugging is .Process of challenging yourself and the assumptions, implicit or explicit, you may have made in your code.

So start with the most essential, and things you are most sure of, and confirm them one at a time.

The less you assume, you more likely you will find the bugs.