Reading RTC counter register value

[togrady]

Posted on March 31, 2008 at 12:20

Reading RTC counter register value

[togrady]

Posted on May 17, 2011 at 12:27

The 32 bit RTC counter register value is read through two 16 bit registers - RTC_CNTH and RTC_CNTL. The ST FWLib does it like this:-

Code:

u32 RTC_GetCounter(void) { u16 tmp = 0; tmp = RTC->CNTL; return (((u32)RTC->CNTH << 16 ) | tmp) ; } What if one of the 16 bit registers ''ticks over'' in between reads. Shouldn't something be disabled to prevent this from happening when reading the RTC counter value. Regards Trevor

[bob239955]

Posted on May 17, 2011 at 12:27

It may be OK to use RTC_GetCounter() from a RTC_CRH SECIE interrupt if we assume we can service it well before another.

If reading the counter asynchronously in the main program this untested function may be used

Code:

<BR>u32 RTC_AtomicGetCounter(void) //assumes RTC_FLAG_SECF not cleared by any interrupts <BR> { <BR> RTC->CRL &= ~RTC_FLAG_SEC; //clear flag that gets set when counter is updated <BR> <BR> u32 counter = RTC_GetCounter(); //read counter <BR> <BR> if (RTC->CRL & RTC_FLAG_SEC) //if counter updated during read it may be unreliable <BR> { <BR> counter = RTC_GetCounter(); //re-read counter (assumes counter not updated again THIS SOON) <BR> } <BR> return counter; <BR> } <BR>

Note it does NOT contain a poll loop that wastes time waiting for a counter update. Or worse, hangs forever. It would be nice if ST put 32bit values in 32bit registers -elsewhere maybe- so we could simply read the u32 register. Or put the 2 16bit halves in consecutive halfwords so they can be cast as a u32. [ This message was edited by: bobz on 31-03-2008 10:32 ]

[togrady]

Posted on May 17, 2011 at 12:27

Hi bobz,

Many thanks for this. This looks like a good solution to me as the tick rate is usually quite slow (1 second). I agree that having to read 32 bit values in two goes is a pain. Maybe ST could implement your atomic version of RTC_GetCounter in the STLib firmware. Hi STOne-32, What is the process for getting STLib updated? How do we report issues and enhancements to the maintainers? Do we just report them here? Regards, Trevor

[bob239955]

Posted on May 17, 2011 at 12:27

Hi Trevor, glad to help. 😉

(If anyone knows how I can stop the < BR > before every line in code snips pls suggest it, seems to happen with my IE6 and IE7 browsers. Did not appear in previews, only appears after clicking send button.) BTW ST: :o There is a small error in the RM0008 revision 3 section 8.5 RTC Register Map, table 32, entry for RTC_CNTH reads CNT[13:16] when it should read CNT[31:16].[ This message was edited by: bobz on 01-04-2008 13:09 ]

[togrady]

Posted on May 17, 2011 at 12:28

Hi bobz,

I guess the other way it could be done is to keep reading 32 bit values until you get two consecutive values the same (usually 2 reads) but this isn't as elegant as your suggestion. Cheers Trevor

[lanchon]

Posted on May 17, 2011 at 12:28

> //re-read counter (assumes counter not updated again THIS SOON)

there's no reason to do this and it's dangerous, it ties the correctness of the code to real-time constraints. what about interrupts? or main clock failures? etc. you should re-check the flag until the condition is met.

[bob239955]

Posted on May 17, 2011 at 12:28

Hi lanchon 🙂 nice to see you're still helping out.

''there's no reason'' are you saying we don't need to worry about reading the 2 halves of the counter asynchronously either side of a counter update? ''dangerous'' are you saying its safe to read the counter once, but dangerous to read it again, despite having good reason, and an excellent chance of improving the situation at no extra risk? ''realtime constraints'' an RTC SEC interrupt would be a good place to read the counter synchronously, but still other higher priority interrupt(s) could prevent it being reached in good time, or the main clock could fail. Or are you saying that will never happen? ''re-check the flag until the condition is met'' - yeah - and get stuck in a loop for up to a second - possibly tripping the watchdog - and that's if everything works properly. Are you saying thats NOT dangerous? Regards, Bob 😉 [ This message was edited by: bobz on 31-03-2008 17:54 ]