• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 78 subscribers
  • Views 275 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP-EXP430FR5994: Out-Of-Box sample code error...

James Nadir
Expert 1120 points
Part Number: MSP-EXP430FR5994

I believe there may be a coding error in the mmc.c fatfs library. The code for get_fattime(void) is provided as follows:

/*-------------------------------------------------------------------------*/
/* Platform dependent RTC Function for FatFs module                        */
/*-------------------------------------------------------------------------*/
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);

	return tmr;
}

The DOS format specification provides 5 bits for the "seconds" field wherein each bit represents a granularity of 2. The count value in the Seconds field is a granularity of 1 sec and uses 6 bits. In the above code the most significant bit overlays the least significant bit of the minutes field. I believe the code should be:

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);

	return tmr;
}

Note that the curTime.Seconds field is shifted right 1 bit which discards the least significant bit making the field a granularity of two (as required by the DOS format). When the fields overlap the timestamps will be inconsistent, some will be correct (when the MSB of Seconds is 0) and some will be wrong when the MSB of Seconds is 1.  While this may not seem much of a problem it could cause havoc with make file which use the timestamp for comparisons. I checked StackExchange to sanity check my understanding. Their code examples also show that the "seconds" field is shifted right 1 bit so I am pretty certain this is an oversight that TI should look into. 

  • 0
    TI__Guru 68011 points

    Hi James,

    Looks like stumbled across a bug.  I also see a related thread you posted.  Let me dig into this.

  • 0 in reply to Dennis Lehman
    TI__Guru 68011 points

    Hi James,

    Looks like you found a solution.


    If this isn’t the case, please click the "This did NOT resolve my issue" button and reply to this thread with more information.
    If this thread locks, please click the "Ask a related question" button and in the new thread describe the current status of your issue and any additional details you may have to assist us in helping to solve your issues.

  • 0 in reply to Dennis Lehman
    Expert 1120 points

    Hi Dennis

    The link in "solutions" is to an earlier problem. That was a problem in understanding the semantics. I also have a solution to the current problem (above) but this is a real code bug and possible compiler problem. 

    1. code bug: the "Seconds" was not shifted to the right in the out-of-box code, hence it violates the DOS date-time bitmap. The fix is simple, shift "Seconds" to the right by 1 bit. 
    2. The most serious problem is that the compiler (under the default optimization settings) is NOT C code compliant. The standard automatically casts the UINT8_T objects to a 16b entity (int, uint16_t, word) so the bits of the "Minutes" and "Hours" fields are not lost. This automatic cast doesn't happen and those fields are lost. The elm-chaN FATFS has unpredictable behavior with illegal date-time stamps (sometimes the date time field is left blank and sometimes there is a strange time date stamp on the directory and/or files). The solution is to explicitly cast the Minutes, Hours to a 16b entity (in another post I cast them to a DWORD. 

    Ok, I have solutions but I believe the code should have explicitly cast the uint8_t entities to a 16b entity. And the compiler should have issued a warning that non-compliant code will be generated for the current settings. I don't think it is realistic to have people turn off all optimizations because of missing casts. Hopefully there aren't other such problems. 

    I put this into another post so I am closing this post. Mr. Winter is looking at it now. 

    thanks

    jim

**Attention** This is a public forum