topic Re: RTC and Sub second Time in Kinetis Microcontrollers

RTC and Sub second Time

leifzars — Tue, 27 Oct 2015 15:10:11 GMT

I would like to keep track of time to the millisecond. How can I do this on a K20? I would like the time to be accurate through low power modes down to VLLS2?

Any ideas ?

Leif

Re: RTC and Sub second Time

egoodii — Tue, 27 Oct 2015 19:05:10 GMT

IF you don't use the 'adjustment' features of the RTC divider chains, so that you can ALWAYS assume 32768 counts per second, then the time-prescale-register (TPR) can get you what you want. Here is my low-level-driver: This code may not be 'perfect', in that I might not be allowing enough time between my dual-reads to account for how SLOW these ripple-counters update themselves...

void _rtc_get_time

(

/* [OUT] this parameter gets actual RTC time */

TIME_STRUCT_PTR time

)

{

uint32_t read1, read2;

do{

read1 = RTC_TSR;

read2 = RTC_TSR;

}while( read1 != read2); //insure the same read twice to avoid 'glitches'

time->SECONDS = read1;

do{

read1 = RTC_TPR;

read2 = RTC_TPR;

}while( read1 != read2); //insure the same read twice to avoid 'glitches'

//Scale 32.768KHz to microseconds, but do the math within 32bits by leaving out 2^6

// 30.51758us per TPR count

time->MICROSECONDS = (read1*(1000000UL/64)+16384/64)/(32768/64); //Round crystal counts to microseconds

if( time->MICROSECONDS < 100 ) //if prescaler just rolled over from zero, might have just incremented seconds -- refetch

{

do{

read1 = RTC_TSR;

read2 = RTC_TSR;

}while( read1 != read2); //insure the same read twice to avoid 'glitches'

time->SECONDS = read1;

}

Re: RTC and Sub second Time

leifzars — Tue, 27 Oct 2015 19:23:33 GMT

Very good, thanks. I didn't understand the TPR register i guess, now i do.

Question why the double read? Is that documented by Freescale?

Re: RTC and Sub second Time

egoodii — Tue, 27 Oct 2015 19:31:50 GMT

Certainly if you look down that link to another thread you will see where one user certainly discovered that 'TPR rollover' did NOT 'instantly' increment the seconds. On a more general note, such a 'very low power subsystem' is intentionally made with 'slow' logic, so the asynchronous count events COULD get 'caught' mid-rollover. Now in my particular case 'always being right' was not important enough to look further into the details, and to whether these dual-reads (and near-rollover-test) are sufficient to guarantee monotonic time-values, as I only use them as console/log timestamps and a 'minor error' on one in a million is of NO consequence.

Re: RTC and Sub second Time

leifzars — Tue, 27 Oct 2015 19:34:17 GMT

Okay, sounds good. Thanks for the knowledge.

I will implement it with the double read.

Re: RTC and Sub second Time

egoodii — Wed, 28 Oct 2015 18:12:36 GMT

This discussion has piqued my curiosity regarding time-read reliability and the desire for time to always 'move forward'. I added this check:

	_rtc_get_time( &rtc_time );
	if( (rtc_time.SECONDS < rtc_time_last.SECONDS)
	\|\| ((rtc_time.SECONDS == rtc_time_last.SECONDS) && (rtc_time.MICROSECONDS < rtc_time_last.MICROSECONDS)) )
	{
	Os_LogDebug(OS_LOG_DEBUG_ERROR, "Time slip. Old:%X.%X, New:%X.%X\n",
	rtc_time_last.SECONDS,rtc_time_last.MICROSECONDS,rtc_time.SECONDS,rtc_time.MICROSECONDS);
	}
	rtc_time_last.MICROSECONDS = rtc_time.MICROSECONDS;
	rtc_time_last.SECONDS = rtc_time.SECONDS;

in my 'idle' loop [most of the time], so about 175,000 checks per second. WITHOUT the protections of the above _rtc_get_time dual-reads and rollover-check, I got about 5 per second of these timestamped [HH:MM:SS.ms] prints showing TPR reads of 'inconsistent' contents due to increment-ripple-in-progress:

[09:12:33.653] ERR: Time slip. Old:56309181.9F9D2, New:56309181.9F808

[09:12:33.736] ERR: Time slip. Old:56309181.B3D1E, New:56309181.B3C48

Turning back 'on' the dual-reads-check knocked them out, but left a few of these at 'TPR rollover' from 999,969us to zero:

[09:15:24.000] ERR: Time slip. Old:5630922B.F4221, New:5630922B.0

[09:15:26.000] ERR: Time slip. Old:5630922D.F4221, New:5630922D.0

When I re-enabled that rollover protection but at '<50us', I got one in 15minutes:

[09:33:27.000] ERR: Time slip. Old:56309666.F4221, New:56309666.3D

This indicates that one(or more) 'interrupt(s)' between the TSR reads and the TPR reads took LONG ENOUGH to make the <50us check 'fail' to protect from seconds rollover: In this case TPR went from '-31us' to '+61us' AFTER we had already read TSR. At the original '<100us' (as above) for the 'rollover time check' I don't expect I would have ever seen a fault, but THAT depends entirely on one's worst interrupt processing interval! Mine is 70us.

I suggest that the entire _rtc_get_time routine should be run with interrupts disabled! The routine only takes 1 to 1.5us at 100MHz. Adding DisableInterrupts and EnableInterrupts around it, I've gotten NO fault in 6 hours!