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.

AM3352: eMMC write issue

Part Number: AM3352

Hello:

I am using ti sdk V03_03_00_04

there is  problem when we test the emmc write using the following code.

double tBetween;

if( clock_gettime( CLOCK_MONOTONIC, &ts_get_before) != 0 )
perror("get clock fail");

fp = fopen(filename, "a+");//a+

for(i = 0; i < FILE_SIZE; i++)
{
buffWrite[i] = (unsigned short)rand();
}
fileLength = fwrite(buffWrite, sizeof(unsigned short), FILE_SIZE, fp);

fd=fileno(fp);

fsyn(fd);
if(fileLength != FILE_SIZE)
{
printf("write file %s error! fileLength:%d \n", filename, fileLength);
fclose(fp);
}
else
{
fclose(fp);
}

if( clock_gettime( CLOCK_MONOTONIC, &ts_get_af) != 0 )
perror("get clock fail");

tBetween=(ts_get_af.tv_sec- ts_get_before.tv_sec)*1000+(ts_get_af.tv_nsec-ts_get_before.tv_nsec)*0.000001;

The FILE_SIZE is  50K,so every time it write 100KB size to the emmc ,I print the tBetween ,In 3 hour test ,it  is about 18s one time ,

sometime about  1 to 1.5 s, but most time it is about 2 ms.

What is wrong?When do the test ,there is no other application run on my board.

Is there any bug exist in the emmc driver ?

  • Hello,

    SDK v3 is quite old and outside our support window. Could you try the more recent v6?

    Also, while I understand there are no other apps running, how do you eliminate the processing done by other kernel tasks?

    Thank you.

  • Liang,

    in addition to what Ron suggested, some comments:

    • The Linux man page for fsync() does not guarantee a certain/max execution time for this function to return. So depending on what other system activity may have gotten queued up I'd expect there to be some randomness and outliers just as you observed
    • How often do you perform this operation?
      • Every second(s) or minutes(s)?
      • What other things does your system do during this time?
        • Try eliminating any other system activity and repeat your test to see if there is an impact
        • You could use 'iotop' (for example in batch mode 'iotop -b -o > logfile.txt') to identify what other I/O operations may be going on during your "18s wait time". You'd need to add that tool to the file system (Yocto recipe), it's not part of the standard SDK build. There are probably other ways to get that same info as well.
    • Why are you manually forcing an fsync()?
      • Do you do this to hope mitigating potential data loss due to unexpected power fail or other events?
        • This alone would not be a bullet-proof solution
        • Can you repeat your test without fsync()

    Regards, Andreas