Why or how does SysTick interrupt wakeup the processor?

I agree with the question. I also read recently about the Systic and it was that it stops during sleep.

May be Freescale has implemented additional mechanism.

Interesting to find out..

Hello Gopal,

although your comment would be reasonable, the SysTick timer is a part of CPU core.

I wonder if Freescale could modify the core logic.

I would like ARM person to confirm SysTick might not be operational in DeepSleep mode.

Best regards,

Yasuhiko Koumoto.

Stopping SysTick when entering Deep Sleep is implementation defined and up to the silicon vendor.

From the Cortex-M4 Devices Guide:

Some implementations stop all the processor clock signals during deep sleep mode. If this happens, the SysTick counter stops.

Note "some" implementations. Without going into too much detail, the processor is driven by HCLK which is derived from FCLK. FCLK is provided by something outside the core logic or integration layer.

The SysTick timer is driven by STCLK which can be sourced in software either from FCLK or an asynchronous, alternative clock - that clock is under control of the SoC clock controller, but which one the SysTick timer uses is software controlled by a single bit in a register.

In Sleep mode, HCLK is gated but FCLK runs - so either STCLK source will keep the SysTick running. In Deep Sleep mode, FCLK is gated, but the asynchronous external STCLK source needn't be.

You can see the current source in the SYST_CSR register (bit 2) - if it is 0, then it demonstrates an external clock source which may continue to run. If it is 1, then it is being derived from the processor clock and will stop ticking in Deep Sleep, as a result of FCLK being gated.

Hello mwsealey,

thank you for your comments.

Your comments might be the correct answer but my experiment with FRDM-KL25Z (Cortex-M0+) and FRDM-K20D50M (Cortex-M4) do NOT follow them. That is, even if SYST_CSR[2]=1, SysTick timer keeps running during Deep Sleep and causes the interrupt.

This is why I made this post. I ask originally about the HCLK (i.e. processor clock) case.

Are there any option not to gate HCLK at Deep Sleep mode?

By the way, according to your answer, HCLK would be gated even in Sleep mode. Isn't it against to Joseph Yiu's answer for my past post?

He said only NVIC and SysTick clock was not gated in Sleep mode.

Best regards,

Yasuhiko Koumoto.

Hello,

It is, in theory, possible to do whatever you like when designing a system. It looks in the integration manual that this is entirely possible, and even a documented possibility (although the details are left to the silicon vendor). The simplest implementation is to just derive HCLK and STCLK from FCLK and gate everything - but for more advanced power management (such as Freescale have done), that isn't fine-grained enough.

Both Joseph and I have stated that this is all implementation defined. The M4/M0+ TRMs and ARMv7-M specifications don't mention anything specifically except that the intent is that the Sleep mode turns off the clock to the processor (HCLK) and Deep Sleep turns off the processor clock and possibly PLLs and flash controller. Optionally, FCLK can be gated at this point, but STCLK may still be running if the external source is in use or if the silicon vendor decided this (FCLK doesn't need to be gated and therefore if both sources for STCLK is derived from it, then it may always run without setting something up other than SLEEPDEEP bit).

A hint comes from the fact that the "PLL and flash controller" mentioned in the TRM are not part of the Cortex-M4 design - not provided by ARM, anyway. The mere mention of these could be treated solely as a suggestion or hint to those designing with Cortex-M.. if your core is in Deep Sleep, then there will be no possibility of CPU access to the flash controller, and no need to run the PLL that supplies the core, which can be a significant power saving.

The intent in real systems is that Sleep is basic clock gating and Deep Sleep is more like an opportunity for low power state retention. Even in this state, it is still possible a designer may want to be able to wake the core on a tick, since the deeper the sleep (and the more complex the power controller managing the clocks and power..) the more likely the requirement to come back out is to basically reset the processor, which is a lot more expensive an operation than simply ungating HCLK.

These questions are probably best asked of Freescale (they have their own Community pages) to try and ascertain exactly what low power mode you would need to be in (if it is not detailed enough in the slides you referenced, or the reference manual for Kinetis) that would disable SysTick but still give you the best trade-off for waking up. In this case, experimenting with the design might show different behaviours, and all I can report here is that this is absolutely intended to be flexible for the ARM Partner implementing the design, so you can expect some SoC to act slightly differently in this regard

Ta,

Matt

Hello Matt,
how about "Devices Generic User Guide"? Isn't it the authorized or official document?
I referred the below statements from "Cortex-M0/M0+ Devices Generic User Guide" at the previous thread.

When the WIC is enabled and the processor enters deep sleep mode, the power management unit in the system can power down most of the Cortex-M0 processor. This has the side effect of stopping the SysTick timer.

Do you say these statements are the implementation matters?

I wonder there are spaces which can be modified by vendors for the NVIC or SysTick which is a part of CPU core. Or does the CPU core have an exclusive STCLK input pin?

Of course, I have already asked the question to Freescale. A Freescale person is currently denying the fact the SysTick will wake up the device from Deep Sleep mode because HCLK should stop during Deep Sleep mode.

To solved the issue, I have already provided the sample code which will reproduce the fact. However, I have not yet received any responces.
I am very confusing now.

Best regards,
Yasuhiko Koumoto.

Do you say these statements are the implementation matters?

The phrasing "the power management unit in the system can power down most of the Cortex-M0 processor" suggests that it isn't necessary to power it down, and implementations may or may not take that opportunity.

The details you want are in the Cortex-M0+ or Cortex-M4 Integration Guide which is available to licensees of the Cortex-M IP in question, and I don't think is suitable discussion on such a public forum.

Needless to say, it isn't something designers are forced to implement on a design, and there are many, many options..

Hello Matt,

OK, I understood what you said although my purpose had not been accomplished.

I would like to close this post.

Thank you for your patient answer.

Best regards,

Yasuhiko Koumoto.

Hello all,

I have gotten the official answer from Freescale AE team.

They are as followings.

It’s not very clear in the manual, but the systick is actually clocked by the platform clock which is the same frequency as the core clock. We don’t really document the difference between the two very well. Since they are the same frequency most of the time it doesn’t matter, but for low power modes it starts to become important. The platform clock runs in WAIT mode, so it is expected operation for the systick to run in WAIT mode and be able to wake you up.

I think the platform clock still be available in STOP mode too, not the BUS clock and this clock's never mentioned in the RM yet.

As the results, it was implementation matter.

However, I have been very much surprised.

I would like to share it with the community.

Best regards,

Yasuhiko Koumoto.