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.

TM4C123FH6PM: TIRTOS - FatFs Raw, creating a new file aborts program

Part Number: TM4C123FH6PM
Other Parts Discussed in Thread: SYSBIOS, , TM4C123GH6PM, EK-TM4C123GXL

Hello Everyone, 

I am trying to port FatSDRaw example to use a USB Mass Storage Device. 

There is no direct example for usb using fatfs directly so I ported the usb example from 129 to 123 first.

I can read the usb stick and open files and read their contents using fatfs calls.

This gives me confidence that the issue I am facing is not USB related. 

However, when I try to create a new file I get a system abort. 

To test If I was doing something wrong I took a FatSDRaw example for 129 and changed SPI parts to USBMscFat and I can create new files without issues.

I have FatFS enabled on my cfg file as well. 

I traced the abort to the following function call by using the debugger. 

ff.c -> f_open -> line 2509 "dw = GET_FATTIME();" 

GET_FATTIME(); is a define that calls get_fattime();

diskio.c get_fattime calls ti_mw_fatfs_getFatTime();

which is implemented in pem4f.c file created by xdc tools. 

Contents of the function are following:

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Int32 ti_mw_fatfs_getFatTime(Void)
{
time_t seconds;
UInt32 fatTime;
struct tm *pTime;
seconds = time(NULL);
pTime = localtime(&seconds);
/*
* localtime() sets pTime->tm_year to number of years
* since 1900, so subtract 80 from tm_year to get FAT time
* offset from 1980.
*/
fatTime = ((UInt32)(pTime->tm_year - 80) << 25) |
((UInt32)(pTime->tm_mon) << 21) |
((UInt32)(pTime->tm_mday) << 16) |
((UInt32)(pTime->tm_hour) << 11) |
((UInt32)(pTime->tm_min) << 5) |
((UInt32)(pTime->tm_sec) >> 1);
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

on the seconds = time(NULL); line the time function is called. 

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
time_t ATTRIBUTE time(time_t *tout)
{
UInt32 t;
/* Seconds_get() returns number of seconds since Jan 1, 1970 00:00:00 GMT. */
t = ti_sysbios_hal_Seconds_get();
#if defined(__ti__)
/*
* TI time() function returns seconds since 1900, so add the number
* of seconds from 1900 to 1970 (2208988800).
*/
t += 2208988800;
#endif
if (tout) {
*tout = t;
}
return (t);
}
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

On line  t = ti_sysbios_hal_Seconds_get(); 

Seconds_get(); function in Seconds.c file is called.

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
UInt32 Seconds_get(Void)
{
UInt32 curSeconds;
UInt32 seconds = 0;
curSeconds = HWREG(HIB_RTCC);
seconds = curSeconds - Seconds_module->refSeconds +
Seconds_module->setSeconds;
return (seconds);
}
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

This is where I get the abort. 

It accesses the Hibernation RTC register so my gut feeling is somehow RTC is not enabled and goes to hardfault.

Did anybody experience a similar issue before that they can help me? 

  • If you are running on a TM4C123FH6PM device, that is the problem. That variant does not have the hibernation module.

  • Hello Bob, thank you for the reply.

    Does tm4c123gh6pm have the hibernation module? 

    Since the ff code calls the generated rtos library which calls the rtos second library isn't it weird that there is no hardware check?  

    There is a sdcard fatfs raw example which must be calling the same thing but I can't really test it since I don't have a sd card breakout board. 

    If I supply my own function from .cfg file fatfs menu and return 0 as the time no file is generated. I suppose it might be thinking the time is null. I'll try returning non zero value. 

    EDIT: Tried returning 1 instead of 0. File got created properly. 

    Could you check the fatsd raw example to see if the call to the seconds function returns a correct value? 

    Thanks,

    Tuna

  • Yes, the TM4C123GH6PM has the hibernation module. Unfortunately I don't have the correct hardware for running that example on the EK-TM4C123GXL LaunchPad. I was able to run the example on the DK-TM4C129X development board. The HIB_RTCC register was zero and stayed zero. When I put the SD card back into my PC it showed no file create date for the two new files.

  • Hello Bob, thanks for the reply.

    After going through datasheets it seems like the only difference is the hibernation module between the two chips. Quite unfortunate but this is embedded so I am not surprised about picking the processor that gave me issues :D 

    Supplying the dummy function resolved the issue. At least the issue was quite easy to debug. 

    Thanks again for all your help,

    Tuna