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
-
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
Sandeep Shetty wrote: Can it be the case that RTC is busy updating some registers Anything is possible when dealing with PC hardware. :-) But I'd more worry about the possible implications of you emitting e.g. out 0x70, 2 /* minute */ then your driver is interrupted by Windows itself wanting to access the RTC (which I presume it assumes it has exclusive access of), emitting e.g. out 0x70, 0 out 0x71, 0 /* set seconds to zero */ and voila, your driver fails. For all I know, the RTC might even have deadlocked at this point. Coming to think of it, is even 0x70-0x73 shared? (you have successfully claimed the address range, by e.g. IoAssignResources?)
-
Sandeep Shetty wrote: Can it be the case that RTC is busy updating some registers Anything is possible when dealing with PC hardware. :-) But I'd more worry about the possible implications of you emitting e.g. out 0x70, 2 /* minute */ then your driver is interrupted by Windows itself wanting to access the RTC (which I presume it assumes it has exclusive access of), emitting e.g. out 0x70, 0 out 0x71, 0 /* set seconds to zero */ and voila, your driver fails. For all I know, the RTC might even have deadlocked at this point. Coming to think of it, is even 0x70-0x73 shared? (you have successfully claimed the address range, by e.g. IoAssignResources?)
Hello!! Thank you for your answer. But I am not using statements like "out 0x70, 2". I am using the macro WRITE_UCHAR_PORT and READ_UCHAR_PORT and pass 0x70 and 0x71 as parameters. I do not think we have to claim addresses and the macro does require on its own. I cam across a small article at site http://www.pcprofile.com/timepiece.HTM#overview There is some problem in chip set INtel 810. Can you please on this? Hope I am on the right track. Please give your suggestions. regards,Sandeep
-
Hello!! Thank you for your answer. But I am not using statements like "out 0x70, 2". I am using the macro WRITE_UCHAR_PORT and READ_UCHAR_PORT and pass 0x70 and 0x71 as parameters. I do not think we have to claim addresses and the macro does require on its own. I cam across a small article at site http://www.pcprofile.com/timepiece.HTM#overview There is some problem in chip set INtel 810. Can you please on this? Hope I am on the right track. Please give your suggestions. regards,Sandeep
Sandeep Shetty wrote: But I am not using statements like "out 0x70, 2". I understand that. I just used that as syntax to keep down on the writing. I do not think we have to claim addresses Is think really a good word to use when dealing with stuff like this? ;-) But it also seems you have to check whether an update is in progress before trying to read anything. Have a look at this for example. I still don't think you are allowed to do this without either disabling interrupts (which I'm quite certain you may not on NT) or claiming the resources you access - even more so since the built-in "System CMOS/real time clock" device already have claimed this I/O range.