A Working Real Time Clock (RTC) Implementation

• Product Design
• Measurement

In one of my projects, data captured from various sensors had to be time stamped in the YearYear/DayDay/MonthMonth, HoursHours:MinutesMinutes:SecondsSeconds format. My initial thought was because there was already a GPRS modem in the system, I could simply configure it to use the network time delivered by the base station when it fired up. Once the GPRS module started up and retrieved the correct time, I could then invoke a simple AT command to read the time stamp into the microcontroller. Once the microcontroller was in a position to request the time stamp as and when needed, I could then deliver this information across the system to all the sub-system components including the data logger.

Once the plan was in place, I reviewed the full AT command list of the modem. There was indeed a command called AT+CCLK which could be used as follows:

AT+CCLK? (to read the current time stamp in the required format)

AT+CCLK=yyddmmhhmmss (to write the current time stamp)

I would only be using the “read” command since the modem would automatically get the network time on start up and write it into its memory. However, upon start up, the modem would always give the factory default time stamp which is 03/01/01, 00:00:00. Even after registering to the mobile network, this time would never get updated.

After doing some investigation on why this was the case, I found out that because the mobile tariff I was on only supported data communication and not voice, the operator would not allow me to access the network time, which meant that I would have to use the factory default time setting of my poor little GPRS modem unless I came up with an alternative solution. The solution was to bring in a real time clock (RTC) in hardware which would become the single point of time reference for my system. Because these clever little devices also have a battery back up, the time reference could be trusted with no external programming for 3 to 5 years. So I started to investigate which real time clock would be suitable for my purposes.

There are a few points to keep in mind while trying to find a suitable RTC. One of the most important feature is the availability of “automatic back up switching circuitry” which will simplify battery maintenance. What this basically means is the RTC uses the system power when it is available rather than draining the coin cell battery installed. Whenever the system power goes down, the RTC automatically (and quickly) switches to the back up battery without losing track of time. Remember that not all of the RTCs will come with this feature. Most of the ones I came across simply operate from the back up battery only.

If you are already using I2C in your system, then integrating an RTC that supports I2C (a.k.a two-wire interface, TWI) will make sense. Most I2C devices will support speeds of up to 400 kbps, which is more than enough for reading and programming an RTC. Note that in order to support speeds of 400 kbps on the I2C, your MCU frequency must be high enough. If you are using an MCU with an insufficient clock rate, you will need to operate at a lower I2C bus speed. In my system, I could only go up to 115 kbps, which worked perfectly fine (my MCU was an AtMega2560 running at 1.8 MHz).

Obviously, besides a small footprint on a PCB, minimal external circuitry is also preferred when choosing an RTC device. A typical external circuitry will involve, a crystal oscillator, a coin cell battery, a couple of capacitors and resistors. Having such few external components will also minimise the risk of your RTC not working when you first build it!

Acquisition and programming of time and date is likely to involve Binary Coded Decimal (BCD) format. For those of you who are not familiar with the BCD format, please have a look at the code snippet I have provided here. You can directly plug this code into the data encoder and the decoder section of your RTC implementation. It has been tested and works as expected.

Some of the RTC devices come with external interrupt functions that allow back up battery voltage measurement as well as various timing functions. If such additional features on an RTC device does not increase the cost of your design too much, I think they are worth having in case you need them at some stage.

After searching for an RTC device, I decided to use PCF8523T from NXP Semiconductor. You can access the datasheet for this RTC here. I bought this part from DigiKey for $0.52 a piece. I used the SO8 package which was not too hard to solder onto a prototype board. Construction was quite straight forward. I simply followed the application information in Figure 36 of the datasheet to build the circuit. You can see the fully functional RTC board I built and use here to get an idea of the final product.

 Although the datasheet will provide all the information the developers will require, I would like to conclude by briefly talking about some of the key features and the advantages of PCF8523T.

 Let me first start by talking about the power requirements of this device. This device draws battery back up current of 150 nA at 3.0V. The back up battery I use is CR1225. The standard capacity of this battery is 48 mAh. In order to understand how these numbers translate into battery life in terms of years, let us do a quick calculation as follows.

 48 mAh / 150 nA = 320 000 hours of life under continuous operation

320000 hours / 24 hours = 13333 days

13333 days / 365 days = 36.5 years of battery life!

I must point out that the above calculations are based on assumptions such as the ambient temperature of 25 degrees C and that the battery is fully charged when installed (i.e. there is no leakage due to shelf storage). Please see the CR1225 datasheet for further information. However, even if this battery lasts for a third of its life expectancy, this means it will not need to be replaced for 12 years! I guess that will do nicely in our system. I must also note that the back up battery will only be needed temporarily in my application as the system will spend most of its life running on rechargeable batteries, which will also be feeding the RTC chip.

PCF8523T also comes with a number of alarm features. The device can be programmed to fire an external interrupt on a given day of the week, at a particular date, hour and minute, which is handy for tracking events.

The device also comes with two independent timers that can be configured as a countdown timer with interrupt. Furthermore, one of those timers can be configured as a watchdog that generates an interrupt upon timing out. Such external timing functions are great if the MCU you are using has very few timers built in.

Another cool feature of this device is that it can generate a clock signal as high as 32768 Hz and as low as 1 Hz in addition to 5 other frequencies in between. This clock signal is accessible via an external pin that can be connected to a microcontroller input. This feature can be used for synchronising discrete system components using RTC as the common clock source.

Finally, the RTC can be programmed to generate an interrupt when the back up battery is running low, this is a great feature to have for battery maintenance. For example, as my system also has a GPRS modem, I can create an SMS alarm to schedule a battery change before the battery goes flat after which the system loses the real time information.

One thing I must mention here is that when I first built this RTC board, I let it run for over 50 hours after which I noticed spurious time and date corruptions. I then changed the device on my board with a new one and this problem disappeared. Even after continuous operation of 120 hours, I did not observe any data corruptions. I think during the first tests the device may have been exposed to electrostatic discharge which may have caused this internal fault. Therefore, I suggest you take care while handling this RTC device while constructing your board. Also, be sure not to overheat the device while soldering it to avoid any risk of failure.

Sign in