RTC month question SSP v1.2.0 vs v1.1.3

SSP v1.2.0 added a validation of the rtc_time_t.tm_mon parameter when calling the RTC driver calendarTimeSet() function.  It checks that the p_time.tm_mon parameter is >= 0 and <= 11.  Is this actually correct.  I thought the tm_mon parameter should be 1 for January and 12 for December and this is how I have been using it with SSP v1.1.3 (which did not validate the parameters) and the RTC has been working fine.

I ran a test and set the date to tm_mon=1, tm_mday=28, and tm_year=117.  I let the RTC clock run so that it eventually changes to the following day and when it does it returns tm_mon=1, tm_mday=29, and tm_year=117.  If tm_mon starts at 0 then this is returning a date of Feb 29, 2017 which is invalid.

I then ran another test and set the date to tm_mon=2, tm_mday=28, and tm_year=117.  I let the RTC clock run so that it eventually changes to the following day and when it does it returns tm_mon=3, tm_mday=1, and tm_year=117.

So it appears the tm_mon should be 1 for January and 12 for December instead of 0 for January and 11 for December.

  • Hey Jeff!

    That sounds interesting - my experience with RTC's is that they follow the "human" way of counting - like you did it: 1-12 for months, 1-31 for days, 0-23 for hours. I'm curious - did you set it at month 11 and see if it switched over to 12 or to 0? I imagine it would be 12.

    Could we get a screenshot of the validation error or warning you get? Thanks!

    -Josh
    RenesasRulz Forum Moderator
  • In reply to jbishop:

    Josh & Jim,

    This is a known bug introduced in SSP 1.2.0. and there is a ticket on this in the defect database.

    The valid value for tm_mon is 0 to 11 as per the date and time structure defined in C standard library <time.h>, however the driver does not increment the value to be compatible with the RTC hardware which has a range of 1..12.

    -Gary
  • In reply to garyj:

    Hey Gary!

    Thanks for letting us know it's being worked on. In the interim, is there a good workaround for Jeff?

    -Josh
    RenesasRulz Forum Moderator

  • In reply to jbishop:

    Josh & Jeff,

    You can work around the issue by changing the following lines in the r_rtc.c driver and then making it read only so that it will not be overwritten by the build.

    In function R_RTC_CalendarTimeSet change the line:

    HW_RTC_MonthSet(p_rtc_reg, rtc_dec_to_bcd((uint8_t) p_time->tm_mon));
    to
    HW_RTC_MonthSet(p_rtc_reg, rtc_dec_to_bcd((uint8_t) p_time->tm_mon + 1));

    In function R_RTC_CalendarTimeGet change the line:
    p_time->tm_mon = (int32_t) rtc_bcd_to_dec(HW_RTC_MonthGet(p_rtc_reg));
    to
    p_time->tm_mon = (int32_t) rtc_bcd_to_dec(HW_RTC_MonthGet(p_rtc_reg)) -1;

    In function R_RTC_CalendarAlarmSet change the line:
    HW_ALARM_MonthSet(p_rtc_reg, rtc_dec_to_bcd((uint8_t) p_alarm->time.tm_mon), (bool) p_alarm->mon_match);
    to
    HW_ALARM_MonthSet(p_rtc_reg, rtc_dec_to_bcd((uint8_t) p_alarm->time.tm_mon +1), (bool) p_alarm->mon_match);

    In function R_RTC_CalendarAlarmGet change the line:

    p_time->tm_mon = (int32_t) rtc_bcd_to_dec(HW_RTC_MonthGet(p_rtc_reg)) ;
    to
    p_time->tm_mon = (int32_t) rtc_bcd_to_dec(HW_RTC_MonthGet(p_rtc_reg)) -1;

    -Gary
  • In reply to garyj:

    Hello,

    According to the UNIX spec for time.h ( pubs.opengroup.org/.../time.h.html ), the correct usage for month is [0,11]. There's a mismatch between hardware and software configuration, since S7G2 UM indicates that "A value from 01 through 12 (in BCD) can be specified" for Month Counter register in the RTC. The driver should perform correct mapping onto tm struct and this is currently not working in the SSP (as Gary indicated).

    Regards
  • In reply to garyj:

    And what about the year? It seems that there is also some problem. Making your corrections to r_rtc.c to solve the months issue, setting tm_year = 117 and letting it run in the demo project RTC_HAL_MG_AP I get

    Get_time: 31-12-2017 23:59:57
    Get_time: 31-12-2017 23:59:57
    Get_time: 31-12-2017 23:59:58
    Get_time: 31-12-2017 23:59:58
    Get_time: 31-12-2017 23:59:59
    Get_time: 31-12-2017 23:59:59
    Get_time: 1-1-1900 0:00:00
    Get_time: 1-1-1900 0:00:00
    Get_time: 1-1-1900 0:00:01
    Get_time: 1-1-1900 0:00:01
    Get_time: 1-1-1900 0:00:02

     

    (note: I'm adding 1900 to the year prior to printf() because the C standard says tm_year is years since 1900)

    Regards

  • In reply to Laboratori Elecsan:

    In fact, any year higher than tm_year = 99 goes to 0 after december 31. Should we use <time.h> as if the offset was 2000 instead of 1900 like the Synergy peripheral?

  • In reply to Laboratori Elecsan:

    Hello Laboratori,

    "time.h" is already included with r_rtc_api.h. RTC on Synergy counts years from 2000 and while the driver should sanitise input/output data, it does not perform it yet. "Year Counter" register can only take BCD values between 0 and 99 so placing 117 in there will cause undefined behaviour (from the manual: "If a value outside of this range is specified, the RTC does not operate correctly"). In this particular case, behaviour is somewhat expected: 117 is greater than 99 so Year Counter will go back to 0.

    For setting the date/time: add 1 to month, take away 100 from the year.
    For getting the data/time: subtract 1 from month, add 100 to the year.

    Should be good until 2100.

    Regards
  • In reply to Renesas Karol:

    Thank you Gary and Karol for your responses.

    So it sounds like in order to use the RTC calendar functions correctly via the Synergy RTC driver, we need to do the following:

    1) rtc_time_t.tm_mon uses the C standard of 0 to 11 but we need to make the changes to r_rtc.c per Gary's instructions until the next revision of SSP.

    2) rtc_time_t.tm_year does not use the C standard of years since 1900 but instead uses years since 2000 and should be in the range of 0 to 99.

    Is this correct? If so, is this documented somewhere, especially the tm_year range since Synergy is not using the C time_t standard? I don't see it in the SSP User Manual nor in any of the code.

    Thanks,
    Jeff
  • In reply to JeffP:

    Thank everyone for all the efforts on this RTC driver. I am developing the product that requires the RTC so I do not need to dig into each driver file to figure out why my month does not work anymore. It could save me quite amount of time.

    Just one suggestion for Renesas support team: whenever there is a new issue found in the formal release, could it be possible to send an email to registered users on a regular basis ( weekly or monthly) about issues and possible workaround before the next release comes out. It could save other developers precious time struggling on the same issue(s).

    Regards,

    Jimmy
  • In reply to Jimmy:

    Hello Jeff,

    RTC driver uses time.h also, but necessary translation between time.h and hardware is not performed at the driver level (use my instructions to do it manually in the API before calendar/alarm set/get functions) - this should be fixed as soon as possible.

    Jimmy, this issue can only be fixed via SSP update and all SSP updates produce notification on the Gallery. Unfortunately there's no way to provide automated notification for this specific issue as it's tracked in our internal system.

    Regards
  • In reply to garyj:

    Hello ,

    I don't find the line you specified for R_RTC_CalendarAlarmGet . I think that it should be the following:
    p_alarm->time.tm_mon = rtc_bcd_to_dec(HW_ALARM_MonthGet(p_rtc_reg));
    to
    p_alarm->time.tm_mon = rtc_bcd_to_dec(HW_ALARM_MonthGet(p_rtc_reg)) - 1;

    Is that correct?

    Regards,
    isaenz.
  • In reply to isaenz:

    Hi isaenz,

    That's right, there should be p_alarm->time instead of p_time.

    Regards,
    adboc