 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Hans Wedemeyer
Joined: 15 Sep 2003
Posts: 226
|
| M41T80 RTC question |
 Posted: Sat Jul 31, 2004 1:33 pm |
 |
|
I'm trying to use the M41T80 RTC chip.
So far things are not so good...
Once synchronized (to GPS) it appears to work but reading it once a second it can produee a wrong time.
The clock is a Dallas 32KHz at room temperture (26oC) should be farily stable for at least a few days.
The read error give the same second count. i.e.
20:33:28
20:33:29
20:33:29
20:33:31
It appears to be keeping time. I think this is a read problem.
I tried both methods for reading. and the problem persists.
Does anyone have any idea what the issue could be ?
Are any known issues with this chip ?
Correction: It does not keep time... Just searched a large data file and found this...
RTC -- GPS
18:05:14 -- :14
18:05:15 -- :15
18:05:17 -- :16
18:05:17 -- :17
18:05:19 -- :18
18:05:20 -- :19
18:05:21 -- :20
Last edited by Hans Wedemeyer on Sat Jul 31, 2004 3:05 pm; edited 1 time in total |
|
 |
dyeatman
Joined: 06 Sep 2003
Posts: 1924
Location: Norman, OK
|
| M40T80 |
| Posted: Sat Jul 31, 2004 2:10 pm |
|
|
Hans,
The M40T80 is a new one on me. Where is the data sheet? Who makes it? |
|
|
Ttelmah
Guest
|
|
| Posted: Sat Jul 31, 2004 2:33 pm |
|
|
Not a chip I have heard of. You will have to post a link to a data sheet.
However some general comments apply:
1) Most such chips, update at their own 'second'. If you set the time, their internal divider, feeding this counter, is not reset (some have seperate commands to do this). Hence, if this timer is due to expire in 0.1 second (say), and you set the time to 14 seconds, then only just slightly more than 0.1seconds latter, th time will advance to the next second.
2) Some such chips have a 'holding register' for the time, and the contents of the counters are latched into this, on the first part of the read instruction. The time read, is then the moment when the instruction started, even if something else (serial I/O for instance), took place in the meantime, delaying completion of the read.
3) In chips that don't have such a holding register, it is vital to read the chip, when the registers are not updating. Hence it is normal to synchronise the read to a signal from the chip, otherwise there can be a problem if the register values change during the read.
Best Wishes |
|
|
Hans Wedemeyer
Joined: 15 Sep 2003
Posts: 226
|
| Sorry wrong chip number it's M41T80 made by ST (SGS) |
| Posted: Sat Jul 31, 2004 3:09 pm |
|
|
| Ttelmah wrote: | Not a chip I have heard of. You will have to post a link to a data sheet.
However some general comments apply:
1) Most such chips, update at their own 'second'. If you set the time, their internal divider, feeding this counter, is not reset (some have seperate commands to do this). Hence, if this timer is due to expire in 0.1 second (say), and you set the time to 14 seconds, then only just slightly more than 0.1seconds latter, th time will advance to the next second.
2) Some such chips have a 'holding register' for the time, and the contents of the counters are latched into this, on the first part of the read instruction. The time read, is then the moment when the instruction started, even if something else (serial I/O for instance), took place in the meantime, delaying completion of the read.
3) In chips that don't have such a holding register, it is vital to read the chip, when the registers are not updating. Hence it is normal to synchronise the read to a signal from the chip, otherwise there can be a problem if the register values change during the read.
Best Wishes |
This one also has a "holding" feature, butthe explanation of it is unclear. It could be read as "the chip stops updating the clock" but I think they mean "the time is latched"...(I hope !) It's a poor data sheet, I've seen better.
In case you need it the M41T80 data sheet is here
http://www.st.com/stonline/books/pdf/docs/9074.pdf
Last edited by Hans Wedemeyer on Sat Jul 31, 2004 3:12 pm; edited 1 time in total |
|
|
Hans Wedemeyer
Joined: 15 Sep 2003
Posts: 226
|
|
|
Guest
|
|
| Posted: Sat Jul 31, 2004 6:01 pm |
|
|
Hans,
First let the thing run for a day or over a weekend and then tell us how for out the time is..
I am guessing like Ttelmah said you are reading the register between time changes. That is the clock is updating but you are reading a cached version of the time.
If your application needs accurate time base consider using the frequency out, square wave out. This will allow the processor to keep the time more accurate than you can read through the I2C interface.
Trampas |
|
|
Guest
|
|
| Posted: Sat Jul 31, 2004 9:02 pm |
|
|
| Anonymous wrote: | Hans,
First let the thing run for a day or over a weekend and then tell us how for out the time is..
I am guessing like Ttelmah said you are reading the register between time changes. That is the clock is updating but you are reading a cached version of the time.
If your application needs accurate time base consider using the frequency out, square wave out. This will allow the processor to keep the time more accurate than you can read through the I2C interface.
Trampas |
Well your last item first.... NO I've tried that. With a whole host of other things going on, there is too much chance of missing an interrupt.
The hardware RTC should do better.
I think Ttelmah is correct, only thing is to figure out where in the code and when to read the chip.
At the moment it's synchronized to the GPS 1PPS Reading the RTC is done just after the 1PPS interrupt (not in) has completed.
The strange effect is it gained time !
Maybe I'll look for a better RTC.... this one costs $1.15
Maybe the price should tell me something :-) |
|
|
Guest
|
|
| Posted: Sun Aug 01, 2004 2:17 am |
|
|
| The chip has an IRQ output what you could set for 1/second. I would use this feature to be sure the read is done right after the second increment. |
|
|
Ttelmah
Guest
|
| Re: M40T80 |
| Posted: Sun Aug 01, 2004 3:28 pm |
|
|
Looking at the data sheet, how are you setting the clock?.
If I wanted to set this, I'd read the GPS time, then add one second to this. Write this into the register map. Then keep writing the 'seconds' value, till the GPS advances to the next second. Every time you write to the chip, the tenths/hundredths counter, is reset, and this will then result in a reasonably accurate 'sync'.
Seperately, another poster has said to use the 1/sec interrupt output to synchronise your read - a _very_ good idea.
The data sheet does say that the clock registers will not update while being read, _but_ it is vital that you use the sequential update mode to read these as a block, if you are not going to see problems (how is your I2C coded....).
Basically, if you read register 1, the value of register 1 will not change during the read. If you seperately read register 1, then 2, then 3, each register will be held during the read, but they can change between the reads. If instead you use the sequential read, all the registers will be held, till the entire block is transferred.
Best Wishes |
|
|
Hans Wedemeyer
Joined: 15 Sep 2003
Posts: 226
|
| Re: M40T80 |
| Posted: Sun Aug 01, 2004 6:49 pm |
|
|
| Ttelmah wrote: |
Looking at the data sheet, how are you setting the clock?.
If I wanted to set this, I'd read the GPS time, then add one second to this. Write this into the register map. Then keep writing the 'seconds' value, till the GPS advances to the next second. Every time you write to the chip, the tenths/hundredths counter, is reset, and this will then result in a reasonably accurate 'sync'.
Seperately, another poster has said to use the 1/sec interrupt output to synchronise your read - a _very_ good idea.
The data sheet does say that the clock registers will not update while being read, _but_ it is vital that you use the sequential update mode to read these as a block, if you are not going to see problems (how is your I2C coded....).
Basically, if you read register 1, the value of register 1 will not change during the read. If you seperately read register 1, then 2, then 3, each register will be held during the read, but they can change between the reads. If instead you use the sequential read, all the registers will be held, till the entire block is transferred.
Best Wishes |
As it turns out the problem was reading it too soon after the GPS 1pps. As the RTC is synchronized to gps, it will also update it's registers at the same time as the gps 1pps (at least unitl the Osc. drifts) I added a few uS delay before reading the RTC and that did the trick.
Synchronizing is a breeze if you know the one trick....
Register 0 is the 1/10 and 1/100 register, and it is read only....... !
It MUST be included in the sync. so just write 00 (yes to a read only reg. ) to it followed by the seconds+1 minutes etc. then hold the YEARS until the "next" 1pps then write the years and it's in sync. In fact reading the RTC at the gsp 1pps give .00 for the 1/10 and 1/100 until the osc. starts to drift.
In my code I only read location 0 after the 1pps and then read the rest of the registers after getting the $GPGGA and $GPRMC strings.
Next ... M41T81 and add some corrections based upon temperature....
Thanks for the help. |
|
|
Ttelmah
Guest
|
|
| Posted: Mon Aug 02, 2004 2:20 am |
|
|
I noticed it referenced being able to 'set' the tenth, and hundredth register, 'but only to 0'. It does provide an easy way to do the sync. :-)
Glad it is working.
Best Wishes |
|
|
Guest
|
|
| Posted: Mon Aug 02, 2004 7:31 am |
|
|
| Ttelmah wrote: | I noticed it referenced being able to 'set' the tenth, and hundredth register, 'but only to 0'. It does provide an easy way to do the sync. :-)
Glad it is working.
Best Wishes |
Correct, however they clearly state wrtting to any other time register will zero the tenth and hundreds... implying it is taken care of ... It's a crappy data sheet, need to much reading between the lines...
from the data sheet...
quote:
A WRITE to any clock register will result in
the Tenths/Hundredths of Seconds being reset to
“00,” and Tenths/Hundredths of Seconds cannot
be written to any value other than “00.”
end quote:
Anyway, thanks for the help. BTW MAXIM are doing a second source for this chip, with a few changes.
hansw |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
