how to configure LPTMR to check how many 100ms have elapsed?

[gauravbanyal]

Hello,

I am using the FRDMKL03z board. In the final product, I will not have an external oscillator.

The use case I want to cater to is that the MCU will be in VLLS3 state with LPTMR running. Every now and then an external interrupt will bring the MCU to Run state. In this state, the MCU should offer to the user how many 100 miliseconds have elapsed since the last time the same interrupt was received.

How should I configure the timer so that I can get this information each time the MCU is woken up? What are the boundary conditions I have to handle in this case?

Thanks!

[mjbcswitzerland]

Hi

VLLS3 can only be woken via a SW reset and so the only real way to do this is to use the RTC (clocked from LPO) so that it maintains its counters in this state.
The SRAM is retained in VLLS3 so the time that the processor went to sleep can be written to a reserved area and the time difference on wake-up (after reset) calculated.

I believe that this functionality is included in the uTasker KL03 project:
http://www.utasker.com/kinetis/FRDM-KL03Z.html

and described in more detail in the documents:
http://www.utasker.com/kinetis/LLWU.html
http://www.utasker.com/kinetis/KL_RTC.html
http://www.utasker.com/docs/uTasker/uTasker_Time.pdf

There is a binary at the first link that allows testing low leakage modes and it manages RTC from LPO by using the technique as explained so that time/date/wake up alarms are still managed in low leakage operation.
Beware however that LPO is not very accurate (a couple of seconds a minute!) so for high resolution a low power 32kHz external oscillator is recommended.

Regards

Mark

[gauravbanyal]

Hi,

I don't quite agree to your response.

The LPTMR (clocked from LPO) can run in the VLLS3 mode and continue to run through the transition of the MCU from VLLS3 to Run modes. So, the LPTMR CTR can maintain the count and this can be read by the MCU when its woken up. Correct? 

Remember that I don't want the LLWU to wake up the MCU. I just need it to maintain a count of time. The wake up will happen via another interrupt source to the LLWU to wake up the MCU.

What I am looking for is the configuration of the timer and pre-scaler to be able to find out how many 100mC have been elapsed since the timer was started. Is it possible in some way that the LPTMRx_CNR increments every 100ms?

Cheers,

Gaurav.

[mjbcswitzerland]

Gaurav

You always need to recover via SW reset and the LPTMR is reset 0 in the process.

That is why I don't think that counting at 100ms will help since you will never be able to read the value.

Regards

Mark

[gauravbanyal]

Mark,

Does the following not mean that the counter will maintain its count?

===============quoted===============

KL03 Sub-Family Reference Manual

32.2 Introduction
The low-power timer (LPTMR) can be configured to operate as a time counter with
optional prescaler, or as a pulse counter with optional glitch filter, across all power
modes, including the low-leakage modes. It can also continue operating through most
system reset events, allowing it to be used as a time of day counter.   

===============quoted===============

Do you have a reference which says that the CNR will be reset when a wake-up happens from VLLS3 or VLLS0 to run, because of an interrupt which uses the LLWU to wake up the core?

Regards,

Gaurav. 

[mjbcswitzerland]

Hi Gaurav

You may indeed be correct that the LPTMR retains its count value across based on the line in the user's manual (which I hadn't noticed before). It is however unclear about what "most system reset events" means and also the register descriptions themselves (which I had checked) do say that the value after a reset is 0. This means that the information is vague and contradicting and so the only way to be sure is to test the mode that you actually use (the next time I have a KL03 connected I'll also do a test so that I know for sure).

Assuming the count value doesn't get reset it means that  there is a possibility of use as you require, but it is limited:

1. You can set the LPO as clock source with a /64 pre-scaler to give a count every 64ms.
2. Since the LPTMR is 16 bits in size it will overflow every 1.16 hours

The result would be that after a reset you have a time value with 64ms resolution (complies with the demand for 100ms) but the longest period in VLLS3 that can be measures is 1.16hours - anything longer and you don't know anymore.

Due to the fact that the LPTMR is 16 bit in size and thus limited I would still recommend the RTC instead - it can measure hundreds of years with 32ms accuracy and is known to operate through resets since that is exactly what its HW was designed to do.

Regards

Mark

[gauravbanyal]

Hello Mark,

Have you been able to check the LPTMR retaining count accross transitions from RUN to VLLS3 and back to RUN? I tried it and now I am having a crash. Details here:https://community.nxp.com/thread/451784 

So I am very interested in the topic right now. If you could try this out and help me here, it will be just great.

Best regards,

Gaurav.

[mjbcswitzerland]

Hi

Yes, I can confirm that the LPTMR in the KL03 holds its values through a reset.

Due to the limited time that the LPTMR can count for I still think that the method is too restrictive in many applications and the RTC would generally be a better solution.

In your other tread I have explained that you still need to enable clocks to the module before you read it - otherwise you will have a hard-fault.

Regards

Mark

[gauravbanyal]

Hello Mark,

Thanks for your inputs. Unfortunately I cannot use the RTC in my case because of the problems discussed in https://community.nxp.com/thread/448280 . I can only use the LPTMR.

Best regards,

Gaurav.

[mjbcswitzerland]

Hi

It depends on your goals - if you need to measure times longer than about 1 hour the LPMTR will not be suitable (since it overflows). If you need higher accuracy than about 5minutes in an hour the LPO as clock to the LPTMR will also not be suitable.

For anything else I would use a low power 32kHz oscillator on the CLKIN in order to not compromise a product than needs these capabilities.

Regards

Mark