Part Number: MSPM0G3107-Q1 Other Parts Discussed in Thread: MSPM0G3107 , SYSCONFIG Tool/software: First things first: The Errata for the MSPM0G3107 (SLAZ742A; checked version dating october 2023) does not mention any such issue. One RTC issue is mentioned but not related to the behaviour observed. A search in the forum using Search - TI E2E support forums did not yield anything related either... The Issue: I configure the RTC to run in Binary mode, i observe the current time value via a proprietary LIN frame which is updated from a date/time buffer variable. The internal date/tme buffer variabte is filled cyclically using the following function. The same Handle is used for the configuration as well and thus the isBinaryFormat member is set to true. void Abstr_RTC_getCurrentTime(Abstr_RTC_Config_t * const rtcHandle, Abstr_RTC_Timestamp_t * const currentTime) { assert(rtcHandle != NULL); assert(currentTime != NULL); while(DL_RTC_isSafeToRead(rtcHandle->registers) == false); // because the read must not take place while the registers are updated await any pending register update to complete before retrieving the current time. (see TRM p. 1506) this loop should run for about 128/32768ths of a second (max.; = ca. 4ms) if(rtcHandle->isBinaryFormat == true) { currentTime->day = DL_RTC_getCalendarDayOfMonthBinary(rtcHandle->registers); currentTime->month = DL_RTC_getCalendarMonthBinary(rtcHandle->registers); currentTime->year = DL_RTC_getCalendarYearBinary(rtcHandle->registers); currentTime->hour = DL_RTC_getCalendarHoursBinary(rtcHandle->registers); currentTime->minute = DL_RTC_getCalendarMinutesBinary(rtcHandle->registers); currentTime->second = DL_RTC_getCalendarSecondsBinary(rtcHandle->registers); } else { currentTime->day = DL_RTC_getCalendarDayOfMonthBCD(rtcHandle->registers); currentTime->month = DL_RTC_getCalendarMonthBCD(rtcHandle->registers); currentTime->year = DL_RTC_getCalendarYearBCD(rtcHandle->registers); currentTime->hour = DL_RTC_getCalendarHoursBCD(rtcHandle->registers); currentTime->minute = DL_RTC_getCalendarMinutesBCD(rtcHandle->registers); currentTime->second = DL_RTC_getCalendarSecondsBCD(rtcHandle->registers); } } The observed behavior is that the time is not updated in the LIN frame (stuck at zero; which can be traced down in the debugger to be down to the driverlib functions invoked in the snippet above returning all zeros.) If the handle is changed to assume the BCD mode (when retrieving the current time; via debugger, the initialization was still previously done with that same handle configured to binary mode ! ) the values in the LIN frame update and show the behavior expected in BCD mode (ie seconds signal jumps from 0x09 to 0x10 for instance) Thus the following assumtions are valid: The RTC power is enabled RTC is supplied the 32khz clock the getCurrentTime function as depicted above does technically work (atleast in BCD mode and there is no reason to believe Binary mode should not work just as well) The RTC is running in BCD mode and the functions reading the Calendar registers in binary mode do not work (which is consistent with TRM chap. 26.3.3.) There is no issue related to the output of the current time via LIN The following steps to narrow down the behaviour have been already performed on my end: change my RTC initialization function to always configure for BCD mode, and configure handle as BCD mode -> LIN Frame shows the current time in BCD format no issues change my RTC initialization function to always configure for Binary mode, and configure handle as Binary mode --> LIN Frame is stuck at all zeros ditch my own RTC initialization function entirely and only use a bare minimum function generated by SYSConfig tool (effectively just a call to DL_RTC_initCalender) configured in Binary mode and use only binary mode part of get current time function --> LIN frame is stuck at all zeros same as before but sysconfig tool generated call to DL_RTC_initCalendar with BCD mode and only using the BCD part of the getCurrentTime fucntion -- LIN Frame shows the current time in BCD format no issues. The following function has been used as an own initialization function void Abstr_RTC_init(const Abstr_RTC_Config_t * const config) { assert(config != NULL); DL_RTC_disableClockControl(config->registers); // stop supplying the 32khz clock to the RTC to ensure that all registers can be written safely without prior checking. static const uint32_t allUsedInterruptsMask = ( DL_RTC_INTERRUPT_CALENDAR_ALARM1 | DL_RTC_INTERRUPT_CALENDAR_ALARM2 | DL_RTC_INTERRUPT_PRESCALER0 | DL_RTC_INTERRUPT_PRESCALER1 | DL_RTC_INTERRUPT_INTERVAL_ALARM ); DL_RTC_disableInterrupt(config->registers, allUsedInterruptsMask); DL_RTC_setClockFormat(config->registers, (config->isBinaryFormat == 1) ? DL_RTC_COMMON_FORMAT_BINARY : DL_RTC_COMMON_FORMAT_BCD); // not present in the sysconfig generated code but should be neccessary from what the description says DL_RTC_initCalendar ( config->registers, config->calendarSettings, (config->isBinaryFormat == 1) ? DL_RTC_COMMON_FORMAT_BINARY : DL_RTC_COMMON_FORMAT_BCD ); if(config->useIntervalAlarm == 1) { static const DL_RTC_COMMON_INTERVAL_ALARM dlIntervalAlarmValues[] = {DL_RTC_COMMON_INTERVAL_ALARM_MINUTECHANGE,DL_RTC_COMMON_INTERVAL_ALARM_HOURCHANGE,DL_RTC_COMMON_INTERVAL_ALARM_NOON,DL_RTC_COMMON_INTERVAL_ALARM_MIDNIGHT}; DL_RTC_setIntervalAlarm(config->registers, dlIntervalAlarmValues[config->intervalAlarmSetting]); } else { // no need to configure the intervalAlarm as it is not used } if(config->usePeriodicAlarm0 == 1) { DL_RTC_COMMON_PRESCALER0_DIVIDE helper; switch(config->periodicAlarmSetting0) { case Abstr_RTC_PeriodicInterval0Settings_4096Hz: helper = DL_RTC_COMMON_PRESCALER0_DIVIDE_8; break; case Abstr_RTC_PeriodicInterval0Settings_2048Hz: helper = DL_RTC_COMMON_PRESCALER0_DIVIDE_16; break; case Abstr_RTC_PeriodicInterval0Settings_1024Hz: helper = DL_RTC_COMMON_PRESCALER0_DIVIDE_32; break; case Abstr_RTC_PeriodicInterval0Settings_512Hz: helper = DL_RTC_COMMON_PRESCALER0_DIVIDE_64; break; case Abstr_RTC_PeriodicInterval0Settings_256Hz: helper = DL_RTC_COMMON_PRESCALER0_DIVIDE_128; break; case Abstr_RTC_PeriodicInterval0Settings_128Hz: helper = DL_RTC_COMMON_PRESCALER0_DIVIDE_256; break; } DL_RTC_setPeriodicAlarm0(config->registers, helper); } else { // no need to configure the periodic alarm as it is not used } if(config->usePeriodicAlarm1 == 1) { DL_RTC_COMMON_PRESCALER1_DIVIDE helper; switch(config->periodicAlarmSetting1) { case Abstr_RTC_PeriodicInterval1Settings_64Hz: helper = DL_RTC_COMMON_PRESCALER1_DIVIDE_2; break; case Abstr_RTC_PeriodicInterval1Settings_32Hz: helper = DL_RTC_COMMON_PRESCALER1_DIVIDE_4; break; case Abstr_RTC_PeriodicInterval1Settings_16Hz: helper = DL_RTC_COMMON_PRESCALER1_DIVIDE_8; break; case Abstr_RTC_PeriodicInterval1Settings_8Hz: helper = DL_RTC_COMMON_PRESCALER1_DIVIDE_16; break; case Abstr_RTC_PeriodicInterval1Settings_4Hz: helper = DL_RTC_COMMON_PRESCALER1_DIVIDE_32; break; case Abstr_RTC_PeriodicInterval1Settings_2Hz: helper = DL_RTC_COMMON_PRESCALER1_DIVIDE_64; break; case Abstr_RTC_PeriodicInterval1Settings_1Hz: helper = DL_RTC_COMMON_PRESCALER1_DIVIDE_128; break; case Abstr_RTC_PeriodicInterval1Settings_0P5Hz: helper = DL_RTC_COMMON_PRESCALER1_DIVIDE_256; break; } DL_RTC_setPeriodicAlarm1(config->registers, helper); } else { // no need to configure the periodic alarm as it is not used } uint32_t interruptsToBeEnabled = 0; interruptsToBeEnabled |= (config->usePeriodicAlarm0 == 1) ? DL_RTC_INTERRUPT_PRESCALER0 : 0; interruptsToBeEnabled |= (config->usePeriodicAlarm1 == 1) ? DL_RTC_INTERRUPT_PRESCALER1 : 0; interruptsToBeEnabled |= (config->useIntervalAlarm == 1) ? DL_RTC_INTERRUPT_INTERVAL_ALARM : 0; DL_RTC_enableInterrupt(config->registers, interruptsToBeEnabled); DL_RTC_enableClockControl(config->registers); // start supplying the 32khz clock to the RTC once it is fully configured (and no earlier) like this the need for checking if writing to the registers is allowed can be avoided NVIC_EnableIRQ(RTC_INT_IRQn); } I currently use the MSPM0 device support files v1.09.01.01 and MSPM0 SDK v2.01.00.03 (which i know are both superseeded -- i just did not get around updating) Any input on why the RTC behaves the way it does is welcome
↧