RTC data (date time) retreival problem

NTDEV
1

Hello All,

I have written a driver which retreives the RTC value. I have used
WRITE_UCHAR_PORT and READ_UCHAR_PORT macros. They operate on port 0x70 and
0x71 respectively to get the RTC value. They are run in a loop of 12. I
get the value properly if run once. But when the values are retreived
continously , over a time it gives all the values as ff. i.e. the date and
time value which are retreved are all 'F’s. The driver does not give any
error. I.e. the driver is correctly binded and everything seems to be
properly executiong apart from the fact that the values reteived for date
and time is all 'F’s. Can it be the case that RTC is busy updating some
registers (at the time of giving error values - all F’s ) so invalid
values are retreived by the driver.
The driver is able to retrieve correct values for once or twice but only
during a long run it gives problem. Could there be some problem in the
hardware or am I missing something.

I am running the driver in Windows XP home OS and on Intel chipsets.

Can you please suggest as to what could be the problem.

Any help would be highly appreciated.

Thanks and regards,
Sandeep

2

There are some particularities that have to be taken into account
when accessing the Real Time Clock. I suggest you should look
for the description of the old MC146818A chip.
You may find also a summarized desciption within the book :
“Undocumented PC”- Author : " Frank Van Geluwe"
( ISBN 0-201-62277-7 )

----- Original Message -----
From: “Sandeep”
To: “NT Developers Interest List”
Sent: Thursday, January 30, 2003 9:42 AM
Subject: [ntdev] RTC data (date time) retreival problem

> Hello All,
>
> I have written a driver which retreives the RTC value. I have used
> WRITE_UCHAR_PORT and READ_UCHAR_PORT macros. They operate on port 0x70 and
> 0x71 respectively to get the RTC value. They are run in a loop of 12. I
> get the value properly if run once. But when the values are retreived
> continously , over a time it gives all the values as ff. i.e. the date and
> time value which are retreved are all 'F’s. The driver does not give any
> error. I.e. the driver is correctly binded and everything seems to be
> properly executiong apart from the fact that the values reteived for date
> and time is all 'F’s. Can it be the case that RTC is busy updating some
> registers (at the time of giving error values - all F’s ) so invalid
> values are retreived by the driver.
> The driver is able to retrieve correct values for once or twice but only
> during a long run it gives problem. Could there be some problem in the
> hardware or am I missing something.
>
> I am running the driver in Windows XP home OS and on Intel chipsets.
>
> Can you please suggest as to what could be the problem.
>
> Any help would be highly appreciated.
>
> Thanks and regards,
> Sandeep
>
> —
> You are currently subscribed to ntdev as: xxxxx@compaqnet.be
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

3

There are kernel function calls to handle this. Look at
KeQueryPerformanceCoujnter and its cousins.

–
Gary G. Little
Have Computer, will travel …
909-698-3191
909-551-2105

“Christiaan Ghijselinck” wrote in message
news:xxxxx@ntdev…
>
>
> There are some particularities that have to be taken into account
> when accessing the Real Time Clock. I suggest you should look
> for the description of the old MC146818A chip.
> You may find also a summarized desciption within the book :
> “Undocumented PC”- Author : " Frank Van Geluwe"
> ( ISBN 0-201-62277-7 )
>
>
> ----- Original Message -----
> From: “Sandeep”
> To: “NT Developers Interest List”
> Sent: Thursday, January 30, 2003 9:42 AM
> Subject: [ntdev] RTC data (date time) retreival problem
>
>
> > Hello All,
> >
> > I have written a driver which retreives the RTC value. I have used
> > WRITE_UCHAR_PORT and READ_UCHAR_PORT macros. They operate on port 0x70
and
> > 0x71 respectively to get the RTC value. They are run in a loop of 12. I
> > get the value properly if run once. But when the values are retreived
> > continously , over a time it gives all the values as ff. i.e. the date
and
> > time value which are retreved are all 'F’s. The driver does not give any
> > error. I.e. the driver is correctly binded and everything seems to be
> > properly executiong apart from the fact that the values reteived for
date
> > and time is all 'F’s. Can it be the case that RTC is busy updating some
> > registers (at the time of giving error values - all F’s ) so invalid
> > values are retreived by the driver.
> > The driver is able to retrieve correct values for once or twice but only
> > during a long run it gives problem. Could there be some problem in the
> > hardware or am I missing something.
> >
> > I am running the driver in Windows XP home OS and on Intel chipsets.
> >
> > Can you please suggest as to what could be the problem.
> >
> > Any help would be highly appreciated.
> >
> > Thanks and regards,
> > Sandeep
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@compaqnet.be
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
>
>

4

Assuming that you really have to read the RTC and not just get the time (in
which case, you should be using one of the standard APIs), there is one big
caveat that you have to keep in mind. NT will occassionally read/write the
RTC to keep the system time in sync – I think it does this hourly or so.
Since the RTC uses an index / data register interface, if both your driver
and NT are accessing it at the same time, one of them will overwrite the
other’s index register, and thus, one of them will end up reading / writing
the wrong register.

As I recall, NT does this at two different times, once at DISPATCH_LEVEL and
once at HIGH_LEVEL. So, if your driver were to raise it’s IRQL to
HIGH_LEVEL before it accesses the RTC, then this problem can be avoided.

We do something like this because we store our system serial number in the
RTC (there are some unused registers there), and so, we discovered this
problem long ago. However, there’s still something odd going on because we
still see that the system time gets messed up on one of our thousands of
systems about once per month, so there’s still some hole someplace… (But
we can’t find it!)