The real-time clock forgets the time.

V

Volo

Member
Hello everyone!
For several years now I have not been able to solve the problem of the loss of the current time by the real-time clock built into Teensyy 4.1.
In those devices that are equipped with a GPS receiver, I correct the time according to the receiver. As soon as it is determined. Unfortunately, this is not possible everywhere.
Increasing the battery capacity to CR123 does not help either. My devices (ground penetrating radars) can be stored in a warehouse for six months or a one year between uses. Usually, after 3-4 months, the RTC forgets the current time.
The only way to restore it is to reflash the program in Arduino IDE. This is very inconvenient, especially since the names of the files with data that I write to the SD card consist of the current date and time.
Also, the procedure for manually installing the RTC is very voluminous, and I have not found such a library function.
I really ask for help.
 
Volo said:
Increasing the battery capacity to CR123 does not help either. My devices (ground penetrating radars) can be stored in a warehouse for six months or a one year between uses. Usually, after 3-4 months, the RTC forgets the current time.
The only way to restore it is to reflash the program in Arduino IDE.
Click to expand...

You can add a very-low power RTC such as RV-3028 to your board, and your battery will last many times longer. No matter how long the battery lasts, though, the RTC is not perfect and it will drift from the actual time. Your application should have a method to let you set the time and update the RTC.
 
I have at least 5 devices and all of them have this problem. Accuracy of several minutes is practically not scary, but the RTC completely loses settings.
At the same time, before switching on, I check the voltage on the battery, everything is normal there and with a large reserve (3-3.1 V).
I want to understand whether this is a regular defect, or I did something wrong. Depending on this, I will decide whether to switch to an external RTC with all the resulting modifications or not.
 
Volo said:
Also, the procedure for manually installing the RTC is very voluminous, and I have not found such a library function.
I really ask for help.
Click to expand...

It sounds like you are also asking how to manually set the clock. I have incorporated that ability in the implementation of my TeensyMIDIPolySynth (TMPS), so I'll provide that as a working example. Unfortunately, I have also experienced the short-lived RTC battery problem, so because of this, I subsequently added this ability to manually set the clock as a work-around.

You'll need to include the following to make use of the time library support:

Code: 
#include <TimeLib.h>

You will need to implement your own functionality to prompt for user input to obtain values for the following variables:

Code: 
// user provided time input values
unsigned int set_time_hour = 0;
unsigned int set_time_minute = 0;
unsigned int set_time_second = 0;

You'll need these additional variables to gather the current time values:

Code: 
// current time values
time_t time_now_hour = 0;
unsigned int time_now_minute = 0;
unsigned int time_now_second = 0;

unsigned long time_now;

The code to actually set the clock, using the user provided input values is as follows:

Code: 
            getTeensy3Time();

            time_now_hour = hour();
            time_now_minute = minute();
            time_now_second = second();

            // remove the current hours, minutes, & seconds from the current time
            time_now = now() - ((time_now_hour * SECS_PER_HOUR) + (time_now_minute * SECS_PER_MIN) + time_now_second);

            // add in the user specified time values
            time_now += ((set_time_hour * SECS_PER_HOUR) + (set_time_minute * SECS_PER_MIN) + set_time_second);

            Teensy3Clock.set(time_now);
            setTime(time_now);

Hope I correctly understood your question & that this might help . . .

Mark J Culross
KD5RXT
 
Volo said:
Depending on this, I will decide whether to switch to an external RTC with all the resulting modifications or not.
Click to expand...
Do yourself a favor and just switch to the external RTC. The battery simply doesn't last when trying to keep the Teensy's RTC running for months, it's really only suitable for protecting against short power blackouts.
 
Thanks Mark for the advice on setting the time.
I also have to set the date.
This is a much more elegant solution than mine.
I'll gladly use it.

Also thanks to jmarsh for the advice.
Now I'll definitely switch to an external RTC.
However, I don't understand at all what the battery has to do with it.
The voltage on it hasn't dropped for a year and the contact with the board is made by soldering (no mechanics).
Most likely, it's something inside the chip.
 
Did the battery have a load on it when you checked the voltage? Ideally you would check both the voltage and current being drawn by the Teensy at the same time.
 
I measured the voltage on the RTC battery with one channel of the oscilloscope.
With the other channel I monitored the supply voltage of 3.3 V during the normal switching on of the device.
The supply voltage increased in a smooth exponential.
I did the same measurements after reprogramming the processor. I did not measure the current, but it was most likely normal.
I did not notice any difference between the measurements.
The battery is Panasonic CR123A (Photo) New 3.29 V. After six months as a buffer RTC 3.26 V.
 
Volo said:
New 3.29 V. After six months as a buffer RTC 3.26 V.
Click to expand...
If it isn't down more than that after 6 months - the RTC is somehow not feeding off of it. That would explain it not holding time.

Is the voltage being read from the Teensy vBat pin against GND? And there will be measurable uA of current used - some posts noted - not sure IIRC it was like 40 uA?

yes ... here ...
sicco said:
I also went for separate RTC chips when a battery backed RTC is needed by the application. But I'm just wondering if better software in a Teensy 4 could get us lower VBAT drain in general.

Because:
if I power up a T4 with only VBAT, i see 43 uA when VBAT is 3V.
if I then plug in USB with 5V, it drops to below 1 uA.
if I hold ONOFF pin low for many seconds, it goes up to 36 uA after going 'OFF' and releasing the pin.
while pulling ONOFF pin low, without 5V supply but with VBAT at 3V, the current is 20 uA higher.
Click to expand...
 
Indeed, I did not conduct a "clean" experiment.
I measured the voltage with different devices. This is most likely a mistake.
Now I measured the consumption current, it is about 29 μA.
With such consumption, the CR123a battery should lose only 8.5% of its capacity in six months.
So, after all, something is wrong with the operation of the built-in RTC.
 
This is unlikely. Because it happens regularly on 5 different devices.
The battery is connected to the cable by welding, and to Teensy 4.1 by soldering without mechanical contacts.
Those devices that have a GPS receiver, after long periods of time, restore the RTC through it.
Those that do not have a receiver simply lose time and start counting from the beginning after power is supplied to the processor.
 
The Teensy 4.1 RTC looks kind of complicated. Looking at the data sheet I see a Real Time Counter but not a Real Time Clock.

With there actually being two counters. A low power counter that runs from the battery and a high power counter. With the HP version having to be set from the LP version by the startup code.

Code: 
    // initialize RTC
    if (!(SNVS_LPCR & SNVS_LPCR_SRTC_ENV)) {
        // if SRTC isn't running, start it with default Jan 1, 2019
        SNVS_LPSRTCLR = 1546300800u << 15;
        SNVS_LPSRTCMR = 1546300800u >> 17;
        SNVS_LPCR |= SNVS_LPCR_SRTC_ENV;
    }
    SNVS_HPCR |= SNVS_HPCR_RTC_EN | SNVS_HPCR_HP_TS;

This bit from startup.c checks to see if the low power counter is running and sets an initial value if not. It then tells the clock system to transfer the counter from the low power counter to the high power counter. (HP_TS)

The manual also says that there is a LP low voltage detection system with a magic number which must be written to a LVD register. I see no evidence of this in the startup code. Which is a problem since it says that this low voltage violation must be cleared first.
 
The manual at 20.3.2 describes the low voltage detector. Where during a low power reset you store a magic number in a particular register. The hardware then compares that to the known correct value. A difference triggers a low voltage violation. Which it says you should clear from the LP Status Register.

Except if there is something to clear there, I can't see it. Where does the output of the comparator go? I have no clue. This thing reads worse than stereo instructions.

Checking the files for the Teensy, I am confused by imxrt.h which defines all of the (many) special registers. Instead of naming it like the manual (LVD), it says:

#define SNVSSNVS_LPPGDR_LPPGDR (IMXRT_SNVS.offset064)

On the plus side, it does define the magic number:

#define SNVS_DEFAULT_PGD_VALUE (0x41736166U)

But neither of these are used anywhere.

Since the Teensy/Arduino environment compiles all of this code each time the IDE starts up, you can modify the code in startup.c to check this register and use that to decide when to store a default value in the low power counter registers.
 
You must log in or register to reply here.
Back
Top