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.

SD Card throughput problem on C6748

Other Parts Discussed in Thread: SYSBIOS, OMAPL138

DSP:  C6748 running at 364.8MHz  (DDR2 running at 300MHz)

Board:  Custom PCB

SYSBIOS:  6.35.0.20

XDCtools:  3.24.6.63

BIOSPSP:  3.00.01.00

EDMA3LLD:  2.11.06.01

Code Composer:  V5.3

File System:  FatFS

SD Card:  Kingston 4GB SDHC micro

 

Everything in our system works.  We can read / write files to the SD card just fine.  However, the time to access the files seems to be very very very slow.  For example, we are attempting to read (4) picture files from the SD card.  Each picture file is around 200kB in size.  It is taking around 6 seconds to read the files.

We are using the PSP / EDMA3 drivers to access the SD card.  The MMCSD_CLK is running at 45.6MHz.  If I understand the SD card interface correctly, that should result in a max throughput of:  45.6MHz x 4 Data lines = 182.4Mbits per sec = 22.8MB per sec.  The (4) files we want to read is around 800kB total, so the access time should be well below 1 second (not the 6 seconds we are seeing).  Someone please confirm my numbers are correct.

Assuming my numbers are correct above, something else must be preventing the C6748 from moving data from the SD card to DDR2 memory quickly.  We have many other things going on in this system.  We are using the LCDC to drive a 1024 x 600 x 16bits per pixel display.  We are also using the Ethernet MAC.  Both of these modules have there own DMA controller to move data between DDR2 and the module.  Furthermore, per TI's recommendation, we have changed the LCDC Master Priority from the default 5 to 0.  The LCDC needs to grab 1024 x 600 x 2 = 1.3MB out of the DDR2.  How fast this happens depends on the PCLK (which we have set to 30.4MHz), horizontal blank time, and the vertical blank time.  My calculations come out to around 24mS per frame.  So that means the LCDC moves 1.3MB every 24mS, plus whatever the EMAC is doing, plus whatever the CPU needs (cache lines).  Now we have added on top of that the SD card access via EDMA3.

Is it possible we are swamping the Switched Central Resource that controls the access out to the DDR2?

What else could cause slow access between the SD card and DDR2?

- Dean

  • Hi Dean,

    Please refer to the SD MMC read throughput published in the SYSBIOS datasheet in the url provided in the wiki below:

    http://processors.wiki.ti.com/index.php/OMAP-L138_Software_Design_Guide#BIOS_Drivers:

    Is it possible for you to check the MMC_CLK on a scope ? or check if the PLL dividers to the MMC module is programmed correctly. What is the buffer size used for DMA transfers.?

    Regards,

    Rahul

  • Rahul,

    Thanks for pointing out the  SD Read Performance link.  Doesn't match my previous 22.8MB per second, and I'm not sure why.  Regardless, 2.2MB per second is fast enough for our application.  Now we just have to figure out why we aren't seeing anything close to 2.2MB per second.

    I have checked the MMCCLK register, and the divider is correctly set for 45.6MHz on the MMCSD_CLK pin.  The scope is coming out on Monday, so I can confirm the clock speed then.  It appears that buffer size doesn't make much of a difference for DMA mode (according to the table).  How do you check what buffer size is used?

    - Dean

     

  • Dean,

    I assume that, you are running the applications like video display, ethernet streaming and SD card read access at same time.
    Can you verify SD card access alone, disable the video and ethernet threads. How is the performance in this case?
    Kindly check the SYSBIOS url for SD card in section 3.4.6 & 3.10 (Refer in BIOS PSP C6748 Datasheet).

  • Yes, we are running multiple TASKS at the same time.  LCD graphics driver, Ethernet sockets, keyboard scanning, etc.  It would take me some time to create a stand alone SD card project, and I agree that I'll probably see the correct 2.2MB speed.  However, I need to make everything work together, so I'm going to put that on the back burner for the moment.

    I did get the scope out today and confirmed the MMCSD_CLK is running at 45.6MHz.  Furthermore, all DAT lines are toggling when data is getting moved.  This confirms the card isn't in some sort of funky 1 data line mode, and is using all the 4 data lines.

    I setup a test project to read a 75kB picture file.  It took 2.4 seconds to read that file (0.03MB per second).  When I look at the MMCSD_CMD and one of the MMCSD_DATx lines, the data is sent in chunks.  There are delay periods of 6mS to 30mS where there is no activity on the CMD or DAT lines.  I can only assume this is the block media task or mmcsd task, getting interrupted   ..or..   the EDMA3 is getting starved by the LCDC DMA.

    blkmediaTask is set to priority 2.  mmcsdTask0 is set to priority 5.  Are the task priorities correct?  Is mmcsdTask0 suppose to be higher than blkmediaTask?  Are there any restrictions from tasks that call, say fopen(), that need to be lower than priority 5?

    Is there any way to raise the priority of a dynamic task?  I would like to raise blkmediaTask and mmcsdTask0 to be higher than anything else in our system, but can't figure out how to change their priority on the fly.

    - Dean

  • Dean,

    You may be looking for the Task_setPri API.

    Or you might want to run a portion of these two tasks as SWIs instead of tasks.

    But to minimize other system coding issues, Task_setPri may do what you want.

    Regards,
    RandyP

  • I tried to use Task_setPri(), however that only works for statically created TASKS.  I can't find a way to get the task handle for dynamically created TASKS.  These TASKS are created by the PSP drivers via the library, and I didn't want to re-compile any of that if I didn't have to.  Same reason why I can't easily change them from TASKS to SWI's.

    - Dean

  • Dean,

    Not sure if we are moving deep into BIOS things or PSP things, but we are quickly getting into things I do not know about.

    For the Task_setPri() function, you need the TaskHandle for the task, which is the return value from the Task_create() function call. Is there nowhere in the PSP that offers a TaskHandle object pointer for you to use?

    Regards,
    RandyP

  • Yes, I know what I need (the TaskHandle), but don't know how to access that via dynamic TASK that I didn't create.  The PSP driver creates this TASK and it is hidden from me.  I can start re-writing the PSP code so I can get access to this handle, but didn't want to go there if there was an "easy" way.

    Any other BIOS experts out there?  Trying to change the priority of a dynamic TASK created by the PSP library.

    - Dean

  • Dean,

    Task_create creates a new task object.
    If successful, Task_create returns the handle of the new task object.
    If unsuccessful, Task_create returns NULL.

    For example, C code can create a Task object as follows:
    Task_Params taskParams;
     
      // Create task with priority 15
      Task_Params_init(&taskParams);
      taskParams.stackSize = 512;
      taskParams.priority = 15;
      Task_create((Task_FuncPtr)myFxn, &taskParams, &eb);

    The following statements statically create a task in the configuration file:(in cfg)
      var params = new Task.Params;
      params.instance.name = "tsk0";
      params.arg0 = 1;
      params.arg1 = 2;
      params.priority = 1;
      Task.create('&tsk0_func', params);
     
      If you want to change the task priority, You have to take the control of task handle through extern variable to another file.
    For reference,

      http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/sysbios/6_21_01_16/exports/docs/docs/cdoc/ti/sysbios/knl/Task.html

     

  • Randy / Pubesh,

    Thanks for trying to help with the dynamic handle.  You guys (or maybe me) are missing the point.  The dynamic TASK is created within the TI PSP library.  I do not have access to the Task_create(), nor can I "see" the TaskHandle that is required to pass into Task_setPri().

    No matter.  I was able to reduce the priorities for all our static TASKS, so PSP block media and sd card TASKS are at a higher priority.  Didn't make a difference.  I even tried to lower the LCDC master priority so it wasn't hogging the DDR2 accesses.  Didn't make a difference.

    Finally, the answer was found deep within the 3rd party GUI code that reads the SD card.  There were two problems.  The first was the GUI library was reading the same file multiple times due to an incorrect naming convention.  Fixing that reduced the SD access time down to around 200mS (was around 2.4 seconds).  The second problem involves the picture format.  We are using .PNG, and apparently that format can be stored in layers.  It is still accessing the SD card 9 times to read one file.  We are still trying to figure how to beat that problem.

    Bottom line, the C6748 and the PSP driver provides us with enough throughput (around 2.2MB per second).  Thanks for your help.

    - Dean

  • Dear Mr. Prabhu,

    I'm starting a new project based on C6748 (LCDK 6748 board) and I need, at start of my program, to read one single file from SD card to DDR2.

    About this argument there is two document OMAPL138_BIOSPSP_Datasheet.pdf and C6748_BIOSPSP_Datasheet.pdf wich report two different throughput rate (both Blockmedia driver) between L138 (11 MBps) and C6748 (2.20 MBps).

    Why is it too big differences on MMCSD read performance between this two devices which I know to have the same peripheral ???

    Thank in advance for your attention,
    Regards,

    Marco

  • Héllo !!

    Coukd you give me please the part of the code that store the vidéo into the SD card. I didn't find examples to do this.

    Thank you