RTOS/CC2642R: FATfs: f_write behavior on a perpetually opened file and current consumption

Hey Seong,

Thanks for the response.  I am using a Fluke 87 with 100ms averaging.

Here is a picture of the setup on one of the boards running a simple blinking led program:

Hey Seong,

I decided to try the 2.40 SDK to see if it would fix the issue but it unfortunately did not (still get FR errors).

After that I tried the 3.10 SDK which also does not work (FR is okay but the file it writes to comes out empty with an impossibly large size for the amount of run-time).

Also here is the portion of the code where the write fails (2.4 SDK) or creates an huge empty file (3.10 SDK):

void inline write_blockdata_to_sd(uint32_t *blockdata, size_t blocksize, uint32_t timestamp){

     timestamp_start = (Clock_getTicks() * Clock_tickPeriod);
  
     fr = f_write(&src, &timestamp, 1 * sizeof(uint32_t), &bytesWritten);
     System_printf("fr after f_write timestamp %d\n", fr); System_flush();
     
     fr += f_write(&src, blockdata, blocksize * sizeof(uint32_t), &bytesWritten);
     
     System_printf("fr after f_write  %d\n", fr); System_flush();
     if(timeToSync)
         {
            fr += f_sync(&src);
            timeToSync = false;
         }
     if(fr){
         //This means we got an error result back from the fsync, or any of the rest of them, for that matter
         RYBfxn(Blue);
         System_printf("THERE WAS AN ERROR HERE\n"); System_flush();
         f_close(&src);
         sd_cleanup();
         CPUdelay(8000 * (1000));
         PIN_setOutputValue(SDCardPinHandle2, SDCARD_VCC, 0);
         SysCtrlSystemReset();
     }
     timestamp_end = (Clock_getTicks() * Clock_tickPeriod);
     timestamp_end = timestamp_end - timestamp_start;
     return;
}

Hi F,

(responding on behalf of Stephen Poanessa)

Thank you for the example. I'm not sure how it applies.  Let me restate the problem.

With the CC2640, we ported a FATFS.  Pseudo code for system operation is:

• Initialize (including f_open)
• Start SCS task to collect data from peripherals
• While (1)
  • SCS reads data from peripherals and buffers in sensor controller memory
  • As the SCS buffer fills, move data to a 2nd buffer using M3 memory
  • Every 900 ms, write the data from the M3 buffer to the SD card (f_write)

With the CC2642, we are trying to use the now-included TI FATFS.

For SDK 2.30 and 2.40, using the same code as above, we receive FR errors (meaning the f_write operation failed).

For SDK 3.10, there are no FR error, but the files consists of nothing but white space.

A power-hungry work-around that provides the correct data to the SD card is this:  

• Initialize 
• Start SCS task to collect data from peripherals
• While (1)
  • SCS reads data from peripherals and buffers in sensor controller memory
  • As the SCS buffer fills, move data to a 2nd buffer using M3 memory
  • Every 900 ms,
    • f_open
    • write the data from the M3 buffer to the SD card (f_write)
    • f_close

Because there is a system call for f_open and f_close every 900 ms, the system power consumption increases from 1 mA (avg) to 20 mA (avg).

We need to understand how to use the TI FATFS without need to close and open the file between each buffer and I don't see anything in the example that would affect this. 

Is there something in the example that must be in place to allow multiple f_writes without need to f_close / f_open between each write operation?

Thanks,

Steve

Hey M-W,

Sorry for the late response, I was pretty sick over the past two weeks and have not been in the office.

Thank you for taking the time to put this great little program together. We compared your example to our code and found that the trick to avoiding the f_open and f_close was changing FIL* src to FIL src. By fixing this issue we were able to determine that it was not just the f_open/close operations that caused the high current consumption. We are now digging into the next layer of debugging to determine its source.

Once again thank you for your time and assistance!

- Stephen Poanessa