MSP-EXP430FR5994: Out-Of-Box sample code setting wrong date in file

Hi James,

As mentioned in the other thread, I'll dig into this and respond shortly.

thank you  Mr. Lehman

I should mention that I am using the RTC in binary format (not bcd as shown in the original out-of-box code below).

I ported the code to interface to a terminal instead of the GUI. this is where I found that the  BCD format scrambles the epoch time in SDCardLog.c. and switched to binary which gave the correct epoch time.

But I am wondering if the FATFS is expecting the RTC registers in BCD format instead of binary.  However, get_fattime() expects binary and I didn't find a BCD to binary conversion (either by the HW or by a SW algorithm) so I assumed fatfs wants binary. If so, why did the original code author (E.Chen) use BCD? Was it for the GUI interface?

/*
 * Real Time Clock Initialization
 */
void Init_RTC()
{
    //Setup Current Time for Calendar
    calendar.Seconds    = 0x55;
    calendar.Minutes    = 0x30;
    calendar.Hours      = 0x04;
    calendar.DayOfWeek  = 0x01;
    calendar.DayOfMonth = 0x30;
    calendar.Month      = 0x04;
    calendar.Year       = 0x2014;

    // Initialize RTC with the specified Calendar above
    RTC_C_initCalendar(RTC_C_BASE,
                       &calendar,
                       RTC_C_FORMAT_BCD);

    RTC_C_setCalendarEvent(RTC_C_BASE,
    		               RTC_C_CALENDAREVENT_MINUTECHANGE
    		               );

    RTC_C_clearInterrupt(RTC_C_BASE,
                         RTC_C_TIME_EVENT_INTERRUPT
                         );

    RTC_C_enableInterrupt(RTC_C_BASE,
                          RTC_C_TIME_EVENT_INTERRUPT
                          );

    //Start RTC Clock
    RTC_C_startClock(RTC_C_BASE);
}

One more observation in my debug efforts..

In the HAL_SDCard.c module the code expects the RTC to be in binary format. The inconsistent use of the RTC format (BCD in Init_RTC() and Binary in Sdcard_setRTC()  ) seems a bit unusual. My current thinking is that somewhere downstream there is a conversion between BCD and binary and that perhaps my code which started as binary gets scrambled. I am currently looking at f_open() and f_sync() to see where they pull the timestamp. 

void SDCard_setRTCTime(Calendar *curTime)
{
    //Initialize Calendar Mode of RTC
    RTC_C_initCalendar(RTC_C_BASE,
    		curTime,
			RTC_C_FORMAT_BINARY);

    //Start RTC Clock
    RTC_C_startClock(RTC_C_BASE);
}

some additional information that might be helpful.

I put a code break at get_RTCTime() in the HAL layer. this is where fatfs fetches the date-time stamp when creating a directory or opening a file. The RTC is not running at the point. The state of the RTC registers are the expected default values set early in main(). Because the RTC is NOT running there should be no synchronization issues reading the time registers. Stopping the program and plugging in the sdcard into windows 10 shows empty date-time fields. The elm-chaN fatfs website that illegal date-time stamps are either ignored or create unpredictable behavior. In this case, the fields are ignored. So fatfs thinks the RTC registers hold illegal values. My first thought was that maybe fatfs wants something other than binary values. I can't imagine what since get_RTCTime() returns a calendar to get_fattime() which seems to expect binary values which it packs the date-time stamp into the 32b DOS format. 

looking at get_fattime() in mmc.c, it casts the uint8_t to DWORD for the most high order bytes (year, month, day) but does not cast the low order bytes which remain in uint8_t. I wouldn't think this is a problem but I am grasping at straws at this point. Somehow the date-timestamp is corrupted going into fatfs and this appears where it might happen.

DWORD get_fattime(void)
{
	DWORD tmr;

	/* Pack date and time into a DWORD variable */
	Calendar curTime = sdInterface->sdGetRTCTime();

	tmr = ((DWORD)(curTime.Year-1980)<<25)
			| ((DWORD)(curTime.Month) << 21)
			| ((DWORD)(curTime.DayOfMonth) << 16)
			| (curTime.Hours << 11)
			| (curTime.Minutes << 5)
			| (curTime.Seconds >> 1); //modified to truncate into two second intervals - jn

	return tmr;
}

I changed it to:

DWORD get_fattime(void)
{
	DWORD tmr;

	/* Pack date and time into a DWORD variable */
	Calendar curTime = sdInterface->sdGetRTCTime();

	tmr = ((DWORD)(curTime.Year-1980)<<25)
			| ((DWORD)(curTime.Month) << 21)
			| ((DWORD)(curTime.DayOfMonth) << 16)
			| ((DWORD)(curTime.Hours) << 11)
			| ((DWORD)(curTime.Minutes) << 5)
			| ((DWORD)(curTime.Seconds) >> 1); //modified to truncate into two second intervals - jn

	return tmr;
}

I then reran my tests. I reran an earlier test which failed to put date-time stamps on my files and directories. This time I have date-time stamps. I need to do more testing.

I ran a second test with different date-time entries with mostly good results. All files and directories now have date-time stamps. However the hours are 1 less than specified (for example I specified 22 hours military time and get 9 PM in the date-time stamp field. I need to find where military time is converted to AM/PM time.  

The hours should now be correctly packed in tmr. I suspect f_sync does the unpacking and will look there next. 

some people I talked think the code should have worked and this is a compiler issue.