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.

CCS/MSP432P401R: RTC ticking incorrectly

Part Number: MSP432P401R

Tool/software: Code Composer Studio

Hello,

I am having trouble with the RTC on the MSP432 with the GNU compiler. The RTC ticks normally, however I notice a weird behaivour where as soon as the minutes or seconds goes over 40, then it reverts back to 0. However after the numbers then reach 19, it will go back to 0 and count to 40 again. This means that my clock ticks as follows: 0,1,2...,38,39,0,1,2...,18,19,0 and so on. This means that it is counting to 60 seconds but rolling over in a weird place. Also if I set the hours to any number above 20, then it throws away the 2 and will only display the second decimal. Example would be setting the hours to 23, and when I call the MAP_RTC_C_getCalendarTime() it displays: hours = 3.

I previously thought I had fixed this by calling ROM_RTC_C_initCalendar(), instead of MAP_RTC_C_initCalendar(). This was a fix for a while, but now it no longer works (with no changes been made to the code). 

A side note is that all of my ROM_XX functions are grayed out in the rom_map.h as the GNU compiler does not want to identify the flag (-DTARGET_IS_MSP432P4XX) set during compile time. Therefore none of the functions with #if defined(TARGET_IS_MSP432P4XX) run. So if I call a MAP_XX it will call the XX function instead of the ROM_XX function. Not sure if this is the cause of the issue with the RTC counting weirdly, but could be a cause. So to be clear if I call MAP_RTC_C_initCalendar(), the ROM_RTC_C_initCalendar() is grayed out and RTC_C_initCalendar() is called instead. 

For extra help with this issue, if I run the following code:

  RTC_C_Calendar currentTime =
 {
         0x46, 	//46 seconds
         0x43,	//43 minutes
         0x23,	//23 hours
         0x01,	//1 day of the week
		 0x16,	//16 day of the month
         0x05,	//5 months
         0x1955	//1955 years
 };
MAP_RTC_C_initCalendar(&currentTime, RTC_C_FORMAT_BCD);
RTC_C_Calendar currenttime;
currenttime = ROM_RTC_C_getCalendarTime();

The value that is returned in currenttime is as follows: seconds = 0x06, minutes = 0x03, hours = 0x03, dayOfWeek = 0x01, dayOfmonth = 0x16, month = 0x05, year = 0x1955. Once the clock is set to run, after 14 seconds the seconds will display 0, and the minutes will display 4.

  • Have you seen this example?

    dev.ti.com/.../

    There is a gcc variant.
  • Hello Chris,

    I have seen that example. I decided to take it a step back and just load the example from the MSPWARE libraries. The rtc_c_calendar_alarm_interrupt example. For some reason I get the exact same behaivour as previously even though this example uses the TI compiler. So again if I load a value of 0x45 into the minutes of the RTC, it will be stored simply as 0x5. Not quite sure what to do from here, if even the example code is not working for me.

  • Jonathan,
    I do not believe that I am seeing the same issue. I can see that the RTC is counting from 0 to 59 seconds and then rolling over to 0 as I would expect. However, the alarm feature is not working as intended and as you point out, using the API to load values into the RTC does not give the correct values. In my case the RTC starts at seconds = 40 instead of 0 and the alarm for 10:04 is never reached even though it does appear that the hour and minute were set correctly by the init API. I will dig into this some more and try to provide some resolution.

    Regards,
    Chris

    PS. At a later point I am going to change the title of the thread to reflect the RTC.
  • Chris,
    That is very interesting because as I mentioned before mine counts from 0 to 40, and then from 0 to 20 again. Interesting enough I am able to trigger alarms, even at a time of 23:44. It can be noted that the RTC shows the time as 3:04 when the alarm is triggered. A solution would be excellent, because I have opened an entirely new MSP432 launchpad from the box and I get the same issues with the standard example.

    Feel free to change the title of the thread, I am new to threads as I usually work until I get a solution instead of posting here, but there seems to be something else here that I cannot fix myself.
    Regards
  • 0245.rtc_c_calendar_alarm_test_01.c
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    /* --COPYRIGHT--,BSD
    * Copyright (c) 2017, Texas Instruments Incorporated
    * All rights reserved.
    *
    * Redistribution and use in source and binary forms, with or without
    * modification, are permitted provided that the following conditions
    * are met:
    *
    * * Redistributions of source code must retain the above copyright
    * notice, this list of conditions and the following disclaimer.
    *
    * * Redistributions in binary form must reproduce the above copyright
    * notice, this list of conditions and the following disclaimer in the
    * documentation and/or other materials provided with the distribution.
    *
    * * Neither the name of Texas Instruments Incorporated nor the names of
    * its contributors may be used to endorse or promote products derived
    * from this software without specific prior written permission.
    *
    * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
    * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
    * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
    * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
    * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
    * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
    * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
    * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
    * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
    * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
    * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
    * --/COPYRIGHT--*/
    /*******************************************************************************
    * MSP432 RTC_C - Calendar Mode
    *
    * Description: This program demonstrates the RTC mode by triggering an
    * interrupt every minute. The date is set at the start of execution and an
    * additional alarm for a specific time is also set to demonstrate the various
    * modes of alarms/events for the RTC_C module.
    *
    * MSP432P401
    * ------------------
    * /|\| |
    * | | |
    * --|RST P1.0 |---> P1.0 LED
    * | PJ.0 LFXIN |---------
    * | | |
    * | | < 32khz xTal >
    * | | |
    * | PJ.1 LFXOUT |---------
    *
    ******************************************************************************/
    /* DriverLib Includes */
    #include <ti/devices/msp432p4xx/driverlib/driverlib.h>
    /* Statics */
    static volatile RTC_C_Calendar newTime;
    //![Simple RTC Config]
    /* Time is November 12th 1955 10:03:00 PM */
    const RTC_C_Calendar currentTime =
    {
    0x00, // seconds
    0x03, // minutes
    0x22, // hours
    0x00, // day of week
    0x12, // day of month
    0x11, // month
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Jonathan,

      I am still evaluating this, but it looks like the pre-compiled library is incorrect.  I have removed the API and replaced with the source found in the SDK (1.40.01).  If you can test and confirm that it works I would appreciate.  I have tested on both CCS and GCC compilers.

    Thanks,

    Chris

  • Hello Chris,

    I tested the code, and I get the same results from it. 

     if(!(iiConvertAll == pastTime[ii].seconds))
            {
                MAP_GPIO_toggleOutputOnPin(GPIO_PORT_P2, GPIO_PIN0);
                MAP_RTC_C_holdClock();
                __no_operation();
            }

    This part here gets activated as soon as the iiConvertAll = 40, and pastTime[ii].seconds = 0. So basically the clock is still ticking over at 40 seconds to 0. I also tested whether the alarm condition is called and if I set the alarm for 1 minute after the clock is started (and deactivate the hold_clock above) then it calls the alarm condition normally. I also checked the time as soon as it was loaded into the RTC (using your custom loading strategy) and if the time that was loaded in was 22:03:00, then the time it displays is 02:03:00, once again throwing away 20 hours. 

    Is it possible that I am using an outdated driverlib for the board? I am not sure why I am getting these results if you say it works fine for you.

  • Jonathan,

    I removed the driverlib API, so that should not be the issue.  Which version of the silicon are you using and what version of the driverlib?

    // MAP_RTC_C_initCalendar(&currentTime, RTC_C_FORMAT_BCD);

    RTC_C->CTL0 = (RTC_C->CTL0 & ~RTC_C_CTL0_KEY_MASK) | RTC_C_KEY;

    BITBAND_PERI(RTC_C->CTL13, RTC_C_CTL13_HOLD_OFS) = 1;

    BITBAND_PERI(RTC_C->CTL13, RTC_C_CTL13_BCD_OFS) = 1;

    RTC_C->TIM0 = (currentTime.minutes << RTC_C_TIM0_MIN_OFS)
    | currentTime.seconds;
    __no_operation();
    RTC_C->TIM1 = (currentTime.dayOfWeek << RTC_C_TIM1_DOW_OFS)
    | currentTime.hours;
    __no_operation();
    RTC_C->DATE = (currentTime.month << RTC_C_DATE_MON_OFS)
    | currentTime.dayOfmonth;
    __no_operation();
    RTC_C->YEAR = currentTime.year;

    BITBAND_PERI(RTC_C->CTL0, RTC_C_CTL0_KEY_OFS) = 0;

    Regards,
    Chris

  • Chris,

    Do you think it might be the RTC_C_getCalendarTime() which is returning incorrect values?

  • Jonathan,

       I have not had any issue with that API.  I would encourage you to look at the registers in the debugger after the  above code initializes the calendar.   These are the differences that I am seeing when I use the API vs when I use the code:

    Please note that in the second case with the API that the BCD register has 40 seconds in it. What version of silicon are you using?  I am using Revision C and revision 2.1 of the MSP-EXP432P401R (red launchpad).

    Chris

  • Hello Chris,

    I am using Revision C and revision 2.1 of the launchpad. I've attached a screenshot of what happens when I set the time to 22h:03m:40s. I've noticed by looking at the registers that the BCD registers loads the correct value, however the other register is incorrect. Therefore the RTCTIM0_BCD register loads 40 seconds into the high and low bit correctly. The RTCTIM0 register however simply loads a value of 0 into it. It says though that it is storing a value of 40 for the seconds, but the actual register reading does not display that. I've highlighted the discrepancy for you in the screenshot.

    The exact same thing happens with the hours. the RTCTIM1 register claims that 22 hours has been loaded into it, and yet when it is read then you can quite easily see that the value 2 has been stored into it. RTCTIM1_BCD however holds the correct time, when the High and Low digit are added together.

    Hopefully this helps you with figuring out the problem. 

  • I decided to check the RTC_C_getCalendarTime() function. I noticed that in the function to get the seconds it was taking the RTC_C->TIM0 & 0x3F. So I changed that to 0xFF. I now get the correct values for the seconds, minutes and hours. The code that I wrote for it can be found below. This, along with your custom loading function seems to have fixed my issue completely now.

    //tempCal.seconds = RTC_C->TIM0 & RTC_C_TIM0_SEC_MASK;
    //tempCal.minutes = (RTC_C->TIM0 & RTC_C_TIM0_MIN_MASK)>>RTC_C_TIM0_MIN_OFS;
    //tempCal.hours   = RTC_C->TIM1 & RTC_C_TIM1_HOUR_MASK;
    tempCal.seconds = RTC_C->TIM0 & 0xFF;
    tempCal.minutes = (RTC_C->TIM0 & 0xFF00)>>RTC_C_TIM0_MIN_OFS;
    tempCal.hours   = RTC_C->TIM1 & 0x3F;

  • Thanks Jonathan. I will file a bug against this.

    Regards,
    Chris

**Attention** This is a public forum