Was there a bug in version 1.0?

[rtek1000]

Hello,

Years ago I had found the DS3232RTC Library v1.0, and used the example to create a mechanical clock control program.

But, a few days ago, I was informed that there have been instabilities in the watch controller.

I noticed a few hours ago that the time changed by itself.

I was using memory addresses numbers 7, 8 and 9 of the DS3231, for general use.

• ADDRESS 07h: Alarm 1 Seconds
• ADDRESS 08h: Alarm 1 Minutes
• ADDRESS 09h: Alarm 1 Hours

myRTC.writeRTC(7, var1); 
myRTC.writeRTC(8, var2);
myRTC.writeRTC(8, var3);

myRTC.readRTC(7);
myRTC.readRTC(8);
myRTC.readRTC(9);

Is there any interference between the writing of addresses 7, 8 and 9, with the current RTC time?

Does the synchronization function use some type of interrupt timer?

setSyncProvider(myRTC.get);

I also noticed that the old example is different from the current example, for example the old one does not have these instructions:

DS3232RTC myRTC;

myRTC.begin();

Current sketch:

// Arduino DS3232RTC Library
// https://github.com/JChristensen/DS3232RTC
//
// Example sketch illustrating Time library with Real Time Clock.
// This example is similar to the example provided with the Time Library.
// The #include statement has been changed to include the DS3232RTC library,
// a DS3232RTC object has been defined (myRTC) and the begin() method is called.

#include <DS3232RTC.h>      // https://github.com/JChristensen/DS3232RTC

DS3232RTC myRTC;

void setup()
{
    Serial.begin(115200);
    myRTC.begin();
    setSyncProvider(myRTC.get);   // the function to get the time from the RTC
    if(timeStatus() != timeSet)
        Serial.println("Unable to sync with the RTC");
    else
        Serial.println("RTC has set the system time");
}

void loop()
{
    digitalClockDisplay();
    delay(1000);
}

void digitalClockDisplay()
{
    // digital clock display of the time
    Serial.print(hour());
    printDigits(minute());
    printDigits(second());
    Serial.print(' ');
    Serial.print(day());
    Serial.print(' ');
    Serial.print(month());
    Serial.print(' ');
    Serial.print(year());
    Serial.println();
}

void printDigits(int digits)
{
    // utility function for digital clock display: prints preceding colon and leading 0
    Serial.print(':');
    if(digits < 10)
        Serial.print('0');
    Serial.print(digits);
}

Old sketch:

/*
 * TimeRTC.pde
 * Example code illustrating Time library with Real Time Clock.
 * This example is identical to the example provided with the Time Library,
 * only the #include statement has been changed to include the DS3232RTC library.
 */

#include <DS3232RTC.h>    //http://github.com/JChristensen/DS3232RTC
#include <Time.h>         //http://www.arduino.cc/playground/Code/Time  
#include <Wire.h>         //http://arduino.cc/en/Reference/Wire (included with Arduino IDE)

void setup(void)
{
    Serial.begin(9600);
    setSyncProvider(RTC.get);   // the function to get the time from the RTC
    if(timeStatus() != timeSet) 
        Serial.println("Unable to sync with the RTC");
    else
        Serial.println("RTC has set the system time");      
}

void loop(void)
{
    digitalClockDisplay();  
    delay(1000);
}

void digitalClockDisplay(void)
{
    // digital clock display of the time
    Serial.print(hour());
    printDigits(minute());
    printDigits(second());
    Serial.print(' ');
    Serial.print(day());
    Serial.print(' ');
    Serial.print(month());
    Serial.print(' ');
    Serial.print(year()); 
    Serial.println(); 
}

void printDigits(int digits)
{
    // utility function for digital clock display: prints preceding colon and leading 0
    Serial.print(':');
    if(digits < 10)
        Serial.print('0');
    Serial.print(digits);
}

Old library attached, for reference only. DS3232RTC.zip Time-master.zip

[JChristensen]

Greetings,

I am unclear on what is meant by instabilities and the time changing by itself (since that is what it does.) Would you please elaborate and be more specific.

I am not aware that setting the alarm registers would have any effect on the time registers.

The setSyncProvider() function does not use interrupts. However, please see the comments in these two example sketches.

Earlier versions of the library instantiated an "RTC" object for the user. This caused a name conflict for some architectures. More details here.

[rtek1000]

I am unclear on what is meant by instabilities and the time changing by itself (since that is what it does.) Would you please elaborate and be more specific.

I noticed a time reduction of a few minutes, for example, it was supposed to go from 11:59 to 12:00, but it showed 11:55

I am not aware that setting the alarm registers would have any effect on the time registers.

The setSyncProvider() function does not use interrupts. However, please see the comments in these two example sketches.

I now used the 400kHz clock, I will do more tests

  myRTC.begin();

  Wire.setClock(I2C_clockFrequency);

  setSyncProvider(myRTC.get);  // the function to get the time from the RTC

Earlier versions of the library instantiated an "RTC" object for the user. This caused a name conflict for some architectures. More details here.

I understand, about the initialization, thanks for the explanation.

[JChristensen]

I have not had reports of a similar issue. I would first suspect something other than the library, possibly a hardware issue. Good luck, and I would be interested to hear if you find the problem.

[JChristensen]

Regarding using the alarm registers for general purpose storage, the datasheet notes that not all values are valid:

The alarms can also be programmed to repeat every second, minute, hour, day, or date. Table 2 shows the possible settings. Configurations not listed in the table will result in illogical operation.

I would assume this means illogical operation of the alarm functionality and not of the time registers, but that would need to be verified.

[rtek1000]

I really do not know. I left the part that uses addresses 7-9 commented out, to test, then I will use these addresses again and see if any problems occur.

The address map shows some bits with a value of 0, but for addresses 7 to 9 there is no such indication:

[rtek1000]

And also the data I was storing is within the range of: 0 to 59 for address 07h 1 to 12 for the address 08h 0 or 1 for address 09h

In other words, bits A1M1, A1M2 and A1M3 are not being used.

[JChristensen]

That should be good, then!