• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 51 subscribers
  • Views 1223 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Compiler/CC2640: f_write to SD card takes a lot of time and tips for power saving?

Huy Nguyen68
Expert 1145 points
Part Number: CC2640


Tool/software: TI C/C++ Compiler

Hello experts,

I'm working on a software on a custom board that has CC2640. Our goal is to achieve 3 day run-time,however, we're only able to run it around~13 hours on 3.7V battery. 

My code involves in sensor controller (SC) and the M3, where SC collects data from sensors and the cpu writes data to SD card. Through profiling, I notice the part that writes to SD card takes a lot of time. Specifically, after the SC collects 288 elements and put them into a buffer of size 288, the snprintf convert int to char array and write to SD card.

//for data from sensor 1
snprintf(value_arr_4b,5,"%04x",value);

//for data from sensor 2
snprintf(value_arr_8b,9,"%08x",value);

The whole process (convert, write to SD card) for a cycle takes about 14 seconds to finish!! Is there anything I can do to speed up the process?

Also, I'm concerned about the power saving of the board, is there anything that people generally could do to save up more power?

Any help or pointer would be greatly appreciated

  • 0
    TI__Guru** 105180 points
    Hi Huy,

    We don't provide a reference for CC26xx BLE + SD cards, so I'm not sure how much I can assist here. I would suggest that you take a bus trace to identify if you are optimally implementing the SD card protocol.

    For power saving, the sample applications are configured to place the MCU in standby when it's not in use. However, if you are doing unnecessary CPU/peripheral operations, that will obviously have a negative impact in allowing the MCU to go into standby. I would also recommend you check for unexpected current leakage in other areas of your board, such as IOs and external components.

    Best wishes
  • 0 in reply to JXS
    Expert 1145 points

    Hello JXS,

    Thank you for your response! I actually found out why the writing to SD process takes too much time. I've been calling f_write and f_sync every time I convert a value in buffer into char array to write to SD card. Calling f_sync after writing all the values in the buffer cut the time in half (~8s), and I think if I manage to convert the whole buffer from uint32_t to char and just call f_write one time, it would further save more time. 

    In our software, we have a semaphore for sensor controller interrupt to notify that the buffer in SC is full. The process would be:

    SC collects data -> SC interrupt (semaphore) -> Copy data to SD card

    If I put the MCU in stanby after the last step (by Task_sleep(n)?), would the interrupt wakes it up or do I need to do any extra configuration?

    Best regards,

    Henry

  • 0 in reply to Huy Nguyen68
    TI__Guru** 105180 points
    Hello Henry,

    It sounds like you are on the right path.

    In terms of sleep/standby, I don't recommend using Task Sleep to force standby. More often than not, you will not achieve your expected results. It's best to just complete your task and let it pend on a SEM. The RTOS will then automatically place the MCU into standby.

    Best wishes
  • 0 in reply to JXS
    Expert 1145 points
    Thank you very much JXS,

    The writing to SD process has been optimized and almost reach to our ideal goal. It's now writing a buffer of ~8k in ~1 second.

    Do you know any way that we can test if the MCU is ever going in standby mode? Our software does pend on semaphore from the sensor controller (when data buffer is full), so I think it's supposed to go to sleep when it's done the task (writing to SD card). Also, is there any way that check if anything interferes the MCU and prevent it go to sleep?

    Best regards,
    Henry