Does register D of the RTC in the ICH8 chip work correctly?
It is supposed to be compatible with Motorola/Freescale MC146818.
Bit 7 should indicate power failure the first time it is read by returning 0.
It seems to always return 1.
Please check the following document, https://www-ssl.intel.com/content/www/xl/es/io/intel-io-controller-hub-8-datasheet.html Intel I/O Controller Hub 8 (ICH8) Family - Datasheet , Section 184.108.40.206 - RTC_REGD-Register D (Flag Register),
the bit 7 is the VRT bit (Valid Ram Time Bit), it is not a power failure indicator.
There are two possible reasons to have a 1 value in this bit:
1) The bit 7 is hardwired to 1 in the RTC power well.
2) It is set to 1 for read cycles.
The ICH8 contains a Motorola MC146818A-compatible real-time clock.
Yes, I have read the datasheet. If bit 7 of REG D is always 1, which is what I am seeing, then the ICH8M is NOT compatible with the MC146818 where bit 7 indicates power failure, and yes, that did work properly.
I also found another bit in the ICH8M, D31:F0, offset 0xA4.
I tried this bit, and it is always 0. So, that bit is also not working in the ICH8M.
This is a big problem for me because I need some way to know if the RTC time is valid or not. If the battery is completely removed, the RTC resets to 1/1/2002. I can detect that. However, the ICH8M has another problem with the RTC. If the battery drops to 0.5V, the clock goes static. When power is turned back on, the clock picks up from where it left off. For my application, a medical device, I need to know if the clock time is valid or not. If it would reset, I could tell by checking it is below some minimum time. If it would freeze and not keep running, I could tell by checking it multiple times and seeing if it is moving. The way it is working now, I have no way of knowing that the clock is not operating correctly.
We are working in your case, in the meanwhile please check the following documents:
http://www.intel.la/content/www/xl/es/intelligent-systems/software/real-time-clock-nmi-enable-paper.... Accessing the Real Time Clock Registers and the NMI Enable Bit, Document # 321088.
Intel ICH Family Real Time Clock (RTC) Accuracy and Considerations under Test Conditions. Document # 292276-008
http://www.intel.com/content/dam/doc/application-note/ich-family-real-time-clock-accuracy-considerat... Intel I/O Controller Hub (Intel ICH) / Platform Controller Hub (PCH) Family Real Time Clock (RTC), Document # 292276-009
True. Our system pulls the latest version which is -009 (April 2012). Gabriel, is there something specific in rev -008 that you wanted to point out? Thanks, LynnZ.
The first document - Accessing the RTC registers is very useful info that is lacking from the main ICH8 datasheet. Fortunately, I had MC146818 example, but that is accessing via legacy, not PCI. That works for all the clock registers except bit 7 of Reg D. Looking at the schematic in the second/third document, Accuracy and Considerations, it does look like VCCRtc is just diode-OR of Vbatt and V3.3. So, if Reg D is reading VCCRtc, it will always be true. It should have a comparator to a ref voltage derived from VCC3.3, with say 2.0V cutoff since that is what the datasheet says is the rated limit.
The difference between the second document and the third are just some figures.
I will send you the second document by email for your reference.
We are checking for previous similar issues and we will contact you as soon as possible.
I just realized that the issue is not because of the internal connections, but the external connections to the ICH8M.
The recommended circuit has 3.3V diode OR'd with the battery.
This would be to make the battery last longer for devices that are on most of the time, but prevents the ICH8M from even having access to the battery directly. Maybe if we lifted the diode on the PCB so the RTC is always powered from battery the REG_D would work, but at what voltage cutoff?
I am checking in similar cases for a voltage cutoff value.
Thanks for the update and I will try to have this information by tomorrow.
The MC146818 is compatible, but you have to take into consideration that a discrete MC146818 CAN be in a slightly different environment than our integrated RTC in the ICH8. Our ICH8 RTC does replicate the functionality of the MC146818 when you take into account how it's "connected" in the ICH8.
The key is the PS (Power Sense) pin. On the MC146818 it is a discrete pin, USUALLY connected to both the System and Battery Back Up power as shown in Figure 14 in the
http://www.freescale.com/files/microcontrollers/doc/data_sheet/MC146818.pdf MC146818 Datasheet , however note that if PS was ONLY connected to the Battery Backup power source, it's very possible that during a read to Register D, if the battery is DEAD, you will read a 0b in bit . Therefore, it is possible to read a 0b in Reg D bit .
In the ICH8, however, the "virtual" PS pin is always going to be connected to power and battery sources (just like in figure 14). PS is always valid during reads to register D. Thus, these reads to register D, bit  are always going to return 1b as stated in the https://www-ssl.intel.com/content/www/us/en/io/intel-io-controller-hub-8-datasheet.html ICH8 datasheet.
Detailed Backup information:
ICH8 Datasheet, page 373 -> RTC_Register D (Flag Register)(LPC I/F-D31:F0)
Default Value: 10UUUUUU (U:undefined)
: Valid Ram and Time Bit (VRT) - R=1b/W=0b
0 = This bit should always be written as 0 for write cycle, however it will return a 1 for read cycles.
1 = This bit is hardwired to 1 in the RTC power well.
: Reserved. R/W = 0b
This bit always returns a 0 and should be set to 0 for write cycles.
[5:0]: Date Alarm - R/W
These bits store the date of month alarm value. If set to 000000b, then a don't care state is assumed. The host must configure the date alarm for
these bits to do anything, yet they can be written at any time. If the date alarm is not enabled, these bits will return 0's to mimic the functionality of
Motorola 146818B. These bits are not affected by any reset assertion.
Freescale MC146818 Datasheet, page 17:
Register D ($0D)
 VRT: The valid RAM and time (VRT) bit indicates the condition of the contents of the RAM, provided the power sense (PS) pin is satisfactorily connected.
A "0" appears in the VRT bit when the power-sense pin is low. The processor program can set the VRT bit when the time and calendar are initialized to
indicate that the RAM and time are valid. The VRT is a read only bit which is not modified by the /RESET pin. The VRT bit can only be set by reading Register D.
[6:0] : Unused: They can't be written, but are always reads as "0's".
PS - Power Sense, INPUT.
The power-sense pin is used in the control of the valid RAM and time (VRT)
bit in Register D. When the PS pins is low the VRT bit is cleared to zero.
When using the VRT feature during power up, the PS pin must be externally held low for the specified tPLH time.
As power is applied, the VRT bit remains low indicating that the contents of the RAM, time registers, and calendar
are not guaranteed. PS must go high after power up to allow the VRT bit to be set a read of register D.
Addressing your main question "I need some way to know if the RTC time is valid or not":
In the RTC there will always be an error rate due to the clock on which it is fed. Even under the best circumstances. So the clock will always be inaccurate up to minutes, if not hours per year. Logically, the only way to verify if a read time is accurate is to compare it to a known good value. Since there aren't any other time sources on a system that run when the machine is powered off, the comparison should be done using a clock's time from the internet. This is what some OS's do, they have the ability to check and/or update the RTC second/minute/hour/day/year registers with these values that were read from the internet.
Regarding your last question about lifting the diode in the OR'd configuration, we need to verify that there is a valid Intel configuration that confirms that this can be done. Could you provide us with your processor and s-spec number if possible? We need to know what platform you're using.
Please check also the section 3.3 RTC Accuracy from the document http://www.intel.com/content/dam/doc/application-note/ich-family-real-time-clock-accuracy-considerat... Intel I/O Controller Hub (Intel ICH) / Platform Controller Hub (PCH) Family Real Time Clock (RTC), Document # 292276-009.
There is no further update. The issue is the external connections to the ICH8M, not internal to the ICH8M.
The recommended circuit has 3.3V diode OR'd with the battery.
Without changing the Single Board Computer design, there is no way to address this.
As a work-around, we check for the date being reset back to 1/1/2002.
We also have confirmation from the battery manufacturer that the battery will die very quickly once it reaches that low level of charge, so the window of exposure of having a low battery is very small.
I am trying to correctly calculate the correct Load Capacitance values using a Intel PCH Real Time Clock.
Conflicting information between Intel Doc # 292276-009 and Pierce oscillator calculation.
From : Doc 292276-009 : Section 3.3 RTC http://www.intel.com/content/dam/doc/application-note/ich-family-real-time-clock-accuracy-considerat... Intel I/O Controller Hub (Intel ICH) / Platform Controller Hub (PCH) Family Real Time Clock (RTC),
CL = [(C1 + Cin1 + Ctrace1)*(C2 + Cin2 + Ctrace2)]/[(C1 + Cin1 + Ctrace1 + C2 + Cin2 + Ctrace2)] + Cparasitic
Pierce oscillator calculation:
CL = [(C1 + Ci )*(C2 + Co)]/[(C1 + Ci + C2 + Co)] + Cs
The difference, is Ctrace is included as part of Cs in the Pierce osc. calc.
Solving for C1 & C1:
Applying both calculations using my values
CL= 12.5pF (from datasheet of crystal)
Cio = 1.5pF: PCH pin capacitance
Cs (C Stray Capacitance)=
+3pF : Vias
+3pF : Trace parasitic capacitance (measured in layout)
6.0pF TOTAL Stray capacitance
Using above values yeilds different load capicator values:
That is a significant difference.
References for Pierce oscillator calculation:http://www.crystek.com/documents/appnotes/PierceGateLoadCap.pdf
Thank you for contacting the Intel Embedded Community.
In order to help you, we will contact you via email.