This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[DM814x RTC] Leap years

Hi,

I'm trying to get my head around the DM814x RTC.

The TRM states: "Counts seconds, minutes, hours, day of the week, date, month, and year with leap year compensation".

So, since the RTC only handles the last two digits of the year, how does it know which century "it" is? Does year "00" mean 1900 (which is no leap year) or 2000 (which is one) or 2100 (which is no leap year again)?


Greetings,
Thomas.

  • Hi Thomas,

    This depends on the SW implementation. Refer to the below pointers for more details:

    linux-kernel/drivers/rtc/rtc-omap.c
    linux-kernel/Documentation/rtc.txt

    e2e.ti.com/.../326747

    BR
    Pavel
  • Hi Pavel,

    thanks for the reply. However, I don't quite understand, what the software implementation using the RTC has to do with how it operates?!

    For example: When I set the RTC (via registers) to: 28/02/00 (DD/MM/YY). When I read out the RTC registers (see TRM, 20.3), I should get (values are already "converted" from BCD):

    YEARS_REG == 0
    MONTHS_REG == 2
    DAYS_REG == 28

    Now, when I just wait one day... Is DAYS_REG == 1 && MONTHS_REG == 3 (which it would be for the year 2000) or DAYS_REG == 29 && MONTHS_REG == 2 (which it would be for 1900 or 2100)?

    IMHO this should be independent from the SW implementation reading the registers?!

     

    Greetings,
    Thomas.

  • Thomas,

    Per my understanding, YEARS_REG = 0, means 1900 (not 2000, not 2100), this is what we have in TRM:

    20.3.6 Year Register (YEARS_REG)
    The year 1979 is programmed as 79 with YEAR0 set as 9 and YEAR1 set as 7.

    See also:
    e2e.ti.com/.../1233741
    e2e.ti.com/.../189742

    BR
    Pavel
  • Hi Pavel,

    thanks for the clarification. I assumed that the "The year 1979 is programmed as..." sentence was an example how to program the year. It was not clear to me that 0 always means 1900 (this note should be added to the TRM).

    However, the consequences are less fortunate since this means, that WEEK_REG renders unusable for all dates after 28/02/2000 (including the complete century!) and all other (date-)registers will be invalid for all dates from 01/03/2000 to 31/12/2000.

    For future designs it would be more secure to have a pure (micro-)seconds counter from a base date (01/01/1900) ;)

    Greetings,
    Thomas