Why does the SDK enable the SysTick interrupt? Apart from incrementing the global uwTick variable, I can’t seem to be able to find any other use case for it.
With deep-sleep enabled, the uwTick variable and the SysTick interrupt does not appear to be very useful. I’m guessing the interrupt handler is not invoked when the CPU is sleeping. With deep-sleep disabled, a SysTick interrupt is generated every millisecond and essentially renders the RTC wakeup interrupt useless.
-Jan
Hi, in the beginning of our SDK we’ve still used some modules from the STM32 HAL library which needed HAL timestamps for timeouts.
I’ve quickly looked now in the current SDK and seems like we have eliminated HAL completely. But some of our projects still could use HAL library in their application logic so this would need to be investigated in more detail. However I would first check how big impact this millisecond timer have on power consumption. I would say it does, but it needs to be measured first. Thanks for pointing that out.
I measured the consumption and the difference in power consumption is almost in measurement error area. With systick I get up to 14.0uA in skeleton firmware, without systick is 13.8uA. But this is measured with multimeter, not oscilloscope and based on how the tasks are running and value is changing is hard to say this was precise enough. so the difference could be even smaller.
Thanks a lot for looking into this! I came to the same conclusion (that it may be needed for some of the HAL code). I wasn’t necessarily advocating for disabling the interrupt, just trying to understand its role.
Also, I have since learned that the interrupt is actually stopped in deep sleep and it won’t wake the core up every millisecond. Since deep sleep is enabled in the skeleton code by default, that may partially explain the small difference in power consumption.
Yes, you’re right that during deep sleep the internal HSI RC oscillator is shut down so the Systick is not running. I forgot that.