• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 354 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.

Problem running SD card interface at full speed on OMAPL138 evaluation board.

Alun Hawkins
Prodigy 55 points
Other Parts Discussed in Thread: OMAPL138

Trying to write an interrupt driven driver for an SD card on the evaluation board, TMDSEXPL138.

Everything works fine with a clock rate of 4MHz, however when increased above this status returns from the MMC/SDcard interface seem to go wrong, see 'scope traces in attachment.

The DATDNE status does not seem to get generated  at the end of the WRITE_BLOCK at 8MHz, looking at the other traces, the SD card seems to be responding correctly. Also, looking at status returned from the WRITE_BLOCK command indicates a successful write.

I have loaded both WindowsCE and Linux demos onto the evaluation board from the SD cards provided with the kit, and they work fine (so there don't seem to be any physical problems with the interface). Also the problem is exactly the same with a selection of SD cards ranging from an ancient 512MB card to a Class 6 8GB card.

I found some TI examples in "evmomapL138_pb.zip", but these seem to be basic hardware test files and are polled.

I also seem to remember someone on this forum mentioning problems with driving SD cards, and TI mentioning that they had some OMAPL138 drivers for internal use, but there were no plans to officially release them.

So ................

(a) Anybody shed any light on my immediate problem.

(b) Can TI send me the source for their unreleased drivers so I can compare and contrast.

Regards,

Alun Hawkins.

  • 0
    Prodigy 55 points

    Some progress. If I poll the BUSY bit after the WRITE_BLOCK data has been sent, then this follows the BUSY status from the card on DAT0. So using this to determine when the write has completed makes everything work (I have a test loop writing and reading blocks and checking for data errors). However, this isn't particularly (processor) efficient, therefore I would ultimately like a completely interrupt driven system.

    I would guess my problem is

    (a) A silicon bug.

    (b) Misconfiguration of the MMC/SDcard interface by me.

    Anyone from TI technical support care to comment?

    Regards,

    Alun Hawkins

  • 0 in reply to Alun Hawkins
    TI__Guru** 116170 points

    Alun,

    The performance for SD card writes seems to be pretty much similar to the performance reported for the linux PSP drivers and WinCE BSP drivers benchmarking.

    http://processors.wiki.ti.com/index.php/DaVinci_PSP_03.21.00.04_Device_Driver_Features_and_Performance_Guide#Performance_and_Benchmarks_3

    http://processors.wiki.ti.com/index.php/ARM9_WinCE_BSP_User_Guide#SD.2FMMC_Host_Controller_Driver

     You mention : "I also seem to remember someone on this forum mentioning problems with driving SD cards, and TI mentioning that they had some OMAPL138 drivers for internal use, but there were no plans to officially release them."

     Can you point us to the thread where this is discussed so that we can check this internally for you.

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Prodigy 55 points

    Not sure I understand your response. I am not talking about the throughput (in MegaBytes/sec), but the basic clock going to the SD card (in MegaHertz). What I am saying is that at 4MHz the DATDNE works fine generating an interrupt, at 8MHz it doesn't (generate an interrupt), so its either a silicon bug or me mis-configuring the interface.

    On the post I half remembered, I tried to find it again, but couldn't (I found it with a string of keywords typed into Google, and, of course, I can't remember the _exact_ sequence). If I do stumble across it again then I will send you details.

    Regards,

    Alun Hawkins.