Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

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.

Delfino 28377D SD Card Writing

Other Parts Discussed in Thread: CONTROLSUITE, TMS320F28379D

Hello All,

I am trying to write data in to a SD Card using a third party FATFS provided by TI(example project), but only 512 bytes of data is being written. The

Subsequent  calls to f_write() or f_lseek after the first call to f_write is setting FA_ERROR flag. Also the  512 bytes will be written provided the file is not empty or created using FA_CREATE or FA_CREATE_NEW. Can someone please explain the behavior or the error . Any help will be appreciated. Thank you

 f_mount(0,&g_sFatFs);

f_open(&g_sFileObject, "0:/Message.txt", FA_READ |  FA_WRITE |  FA_OPEN_ALWAYS );

 ReadCount = 512;

 f_read(&g_sFileObject, line, ReadCount, &Count);

 size = (&g_sFileObject)->fsize;

while(count < 10){

    fresult = f_lseek(&g_sFileObject,size);

    f_write(&g_sFileObject, &DMABuf1, sizeof(DMABuf1),&Count);

    count++;

    }

  • Hi,
    I think I remember people having trouble writing because FATFS opened the file system as read only by default, but I'm not 100% sure. You mention that the FA_ERROR flag is set. What do the seek and write functions return. We may be able to gain some insight from this.

    http://elm-chan.org/fsw/ff/en/rc.html

    BR,
  • hi,


    Thanks for the reply.

    The seek and write functions are all returning FR_OK.

    f_open(&g_sFileObject, "0:/Message.txt", FA_READ | FA_WRITE | FA_OPEN_ALWAYS );

    The file is being opened in read as well as write mode. So no problem in accessing the file for writing; infact I am able
    to write the first 512 bytes. I observed that SPI slave is not responding when I send two dummy bytes(for CRC) after
    transmission of 512 bytes of data. I am using a 4GB SD card.

    Regards
    Gurudutt
  • Hi, I am facing exactly the same issue on Delfino 28377D . There is absolutely no help regarding SD card facing with Delfino. Even the ControlSuite example does not give any clue about writing to SD.
  • This problem is due to this code segment in xmit_datablock() routine of mmc-F2837x.c

    BYTE wc;
    ...............
    wc = 0;
    do /* Xmit the 512 byte data block to MMC */
    {
    xmit_spi(*buff++);
    xmit_spi(*buff++);
    }

    Here wc is supposed to be an 8-bit data type so that the do-while loop runs for exactly 256 iterations (512 writes). But since BYTE is unsigned char which is 16-bit in TI microcontrollers, the loop ends up running for 65536 times!
    Thus only first 512 bytes are written. Simply change wc = 256 and it should start working.

  • Hello,

    Is your problem resolved? I am working on a project that involves data logging of several sensors connected via ADC and SPI. I am having hard time to make writing to SD card work. Would you mind sharing a sample project if you got it working? I have TMS320F28379D. I appreciate your help.

    Regards,

    Archit
  • Hi Archit, I do not have a sample code as you ask. The code that I wrote was part of a larger propriety code. But as I mentioned in my previous code, if you change the lines in the TI supplied code, then it should work as intended. You may share the code that you have written and I may be able to help you debug it.

    rgds

  • Hello Muhammad,

    Thank you for your message. So, I was able to write to the SD Card in CSV format. How ever its extremely slow and I am not able to understand the reason and what can I modify to fix the issue. The requirement is to write about 24 floating point numbers to the SD Card every 50 micro seconds. However, CPU takes about 20 micro seconds to compute those numbers and so essentially CPU shall not take more than about 25 micro seconds to write 24 floating point numbers to the card. Below is the sample code that I have been using.

    f_open(&g_sFileObject, "0:/Message.csv", FA_READ |  FA_WRITE |  FA_OPEN_ALWAYS );
    ReadCount = 512;
    size = (&g_sFileObject)->fsize;
    
    ////////////////////////////// SECTION 2 //////////////////////////////////////
    
    fresult = f_lseek(&g_sFileObject,size);
    f_write(&g_sFileObject, "1000.00,1001.00,1002.00,1003.00,1004.00,1005.00,1006.00,150,151,152,1,10000,10001,10002,360.1234\n", sizeof("1000.00,1001.00,1002.00,1003.00,1004.00,1005.00,1006.00,150,151,152,1,10000,10001,10002,360.1234\n"), &Count);
    f_sync(&g_sFileObject);
    
    ////////////////////////////// END SECTION 2 //////////////////////////////////////
    
    f_close(&g_sFileObject);

    So, basically the code enclosed in "SECTION 2" has to occure every 50 micro seconds. Using the clock tool in Debug Mode, I tried to calculate the ticks and it turns out that the logic in "Section 2" takes about 5 milli seconds. I then tried to dubug the code even further and here is what I found:

    1.) f_lseek takes about 2 milliseconds

    2.) f_write actually only takes about 10 micro seconds. (And I have not even enabled FIFO and DMA)

    3.) f_sync takes about 2.9 milliseconds.

    So then I tried not to use f_sync to reduce the time, but if I dont execute it every cycle, data is not being written. And for the f_lseek function there is a f_read statement which takes all the time. And so, I tried to comment out that statement and data is not being written then. So, it seems that I am stuck now and have no idea what can I do to achieve the requirement.

    Please provide some insight on what and how to modify the code to make the timing achievable and reliably perform data logging. Also, at this point I am converting all the floats to string using "ltoa" and thats an inefficient way to do the data logging. Suggestions please.

    I thank you for your time and appreciate your help.

    Regards,

    Archit

  • Hi Archit,

    I think the reason f_write is only taking 10 micro seconds is that this function only write to the buffer and not the hardware storage itself. f_sync on the other hand ensures that buffer is "synced" i.e. the data is flushed to the actual storage device and that's why it is taking longer. SD writes via SPI link are supposed to be slow and your requirement of writing 24 floating point numbers in 25 microseconds (4 bytes per micro seconds) is a bit too much for the hardware to handle. 

    rgds