µTasker KL RTC Support

The KL family of Cortex M0+ based devices are designed for low power use. A little surprising is however the fact that it is not possible to make use of this when a RTC is required without adding an external low power 32.768kHz oscillator module. If you check out the Freescale KL boards you will notice that the tower evaluation boards will in fact include such a low power oscillator but the low cost Freedom boards will not. This means that Freedom board owners are limited in the use of the RTC without either adding an external oscillator to the RTC_IN pin or replacing the 8MHz crystal with a 32.768kHz one.

The following image shows the RTC part of a typical KL device:

Typically the RTC counter can be clocked from either the RTC_CLKIN (which is used by the TWR-KL46Z48M for example), the LPO (1kHz low power RC clock) or OSC32KCLK (from the crystal oscillator).
What is however not initially clear is that OSC32KCLK is only available when the crystal used is a 32.768kHz crystal, which is usually not the case. {reference} Therefore this option is generally not viable, the RTC_CLKIN is also not available on most boards, thus leaving the LPO as the only clock that can be used (without modifications).

For the reason above the default RTC clock on KL Freedom boards is thus the LPO. If you enable the RTC using SUPPORT_RTC the option RTC_USES_LPO_1kHz is valid by default. Should you modify the board or configure for your own that does have an external oscillator on RTC_IN you can select RTC_USES_RTC_CLKIN instead (as the tower board configurations do). The accuracy of the RTC driven from the LPO is of course not very high since the LPO, although it is trimmed and can be further trimmed in the circuit, is not so good or stable as a crystal source. If designing circuits with the KL devices that need a RTC it is therefore recommended to use a tower board's circuit as reference and add a good quality low power oscillator to drive the RTC which will then allow accuracy and low power modes to be used sucessfully.

One side effect of the RTC module is when the KL device includes a segment LCD (SLCD) and also needs to use low power modes. The clock ERCLK32K, which is selected for use by the RTC, is often shared with other peripherals and in the case of using the LPO as RTC clock it also means that the same clock is used for other peripherals hanging in the same clock signal (ERCLK32K). The SLCD requires a clock input that is in the 30kHz..39.063kHz range to be able to operate and it become obvious that it can't use the ERCLK32K if this is selected as the 1kHz LPO. In normal operation modes this is not a big deal because the SLCD can instead be clocked from the MCGIRCLK (32kHz or 4MHz interal RC clocks). Also the low power stop and VLPS modes are possible because the MCGIRCLK can continue to operate in them. The LLS/VLLS modes are however excluded!

Using LPO to achieve RTC functionality

If high accuracy is required the only real solution is to use a low power oscillator driving the RTC_CLKIN input and use the very low power modes of the KL device with battery backup in this state. However there will be applications that would prefer to not need an external oscillator to acheive a low current battery backed up solution and don't mind the inccuracy of the LPO. For example, it may be required to switch to a very low power mode for one hour (with a couple of minutes accuracy acceptable) or perhaps for 100 days (again with an acceptable tolerance when it could be a couple of days early or late). The following details the RTC_USES_LPO_1kHz option in the µTasker project to allow the RTC to count in seconds during normal operation and maintain a very low power measurement of time during low leakage modes where currents of around 2uA are possible.

In normal operating modes (including WAIT, STOP and VLPS), where interrupt servicing is possible, the second interrupt is used to prime the RTC's prescaler so that the next second interrupt occurs after another 1000 LPO clock cycles. This allows the RTC to achieve second counting and a seconds interrupt based on the the RTC's use of the LPO without the need for a 32.768kHz source.

In low leakage modes, where the LPO continues to operate, the use of interrupts is not generally possible (eg. VLLS3 which can only be exited via a reset) and even waking temporarily to service a 1s interrupt in LLS mode is best avoided. Therefore it is accepted that the RTC is clocked at 1kHz and thus counts 1/32.768 times slower that second counting. When the KL device is set to a low power mode with the knowledge that it should wake at a point of time in the future due to a RTC alarm the alarm value is set to take into acount the clock source used; for example, if the alarm is set for 10 hours in the future the alarm counter value remaining is simply reduced by a factor or 1/32.768 so that it fires at the appropriate time. The seconds and prescale count values at the time of entry to the low leakage power mode are saved to RAM locations that will be retained across a warm reset so that the elapsed time during the low power state can be calculated and the RTC seconds are corrected by using the scaling of x32.768. If the wakeup reason is not due to the RTC alarm wakeup - for example it could have been due to a Low-Leakage Wakup pin

not only the present time can be calculated and reinstated but also a programmed alarm time can be corrected by the adjusting its value to be equal to its original seconds setting. The RTC prescaler value is readable and so the 1s resolution of the RTC is not lost.

The LPO is factory trimmed but due to its nature (RC oscillator) it is not highly stable over the usable temperature range. Additional trimming is possible in the application since the RTC has registers that can be used to fine tune the frequency.

But my KL02 doesn't have a RTC...

There are KL processors, such as the KL02, that don't include a RTC but this doesn't fully exclude them from being used for software based RTC functionality. The same interface and features are possible, including maintaining the time over resets, by enabling the define SUPPORT_SW_RTC in the µTasker project framework. More details and a binary file to see it in action can be found at FRDM-KL02Z Software Based RTC.

Since the software based RTC requires basic software functionality there may be of course some restrictions to being able to fully operate in some low leakage modes or for waking the processor from such.

This software RTC functionality is also valid for the KV10 devices, which also have no inbuilt RTC.

For specific questions and feedback please use the following forum entry: KL RTC forum