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.

CCS/TDA3LA: Buffer management problem with SDIO interface

Part Number: TDA3LA
Other Parts Discussed in Thread: TDA2

Tool/software: Code Composer Studio

Hi

I have a problem with SDIO exchanging data. 

When I read data from SD card it goes normally. Before reading transaction I'm waiting for BRR flag of MMC_STAT and when it sets to 1 I make a reading,
But when I try to write some data into block of SD card it has a problem. When I'm waiting for BWR it doesn't set to 1. It's equal to 0 always.

What's wrong?

  • In addition to question.

    Needed bits in PSTATE register WTA (write transfer active) and BWE (buffer write enable) are in High state. They indicate that the buffer is ready to transfer

  • Hi Ivan,

    If I understood correctly, you are testing an SD memory card? If this is the case, please note that in TDA3x, the MMC module's capability was limited to SDIO cards/interfaces only. SD/MMC memory cards are not supported.

    Regards,

    Stan

  • Hi, Stan

    Are you sure?

    Because now I see in datasheet, that TDA3x supports MMC/SD/SDIO

  • Ivan,

    I'm pretty sure. MMC module in TDA3  was restricted to SDIO from the very beginning. Actually, this is the MMC4 module known as a SDIO interface in earlier SoCs like TDA2 and DRA75x.

    MMC1 which is for eMMC and MMC2 dedicated to MMC/SD cards are not supported entirely.

    You are right  - datasheet is showing SD and MMC cards Will check this internally with team. Most probably this is an document error.

    Actually SDIO cards use the same protocol (correct me if I'm wrong) as SD cards, therefore it could be possible SD card to work. One of the problems to solve will be handling of Write Protect and Card Detect pins which are missing on TDA3 (for example via GPIO). Currently, in your case,  the SW driver may 'think' that SD card is write protected.

    However, please be aware TI will not be able to assist you further since SD card on TDA3 wasn't tested and validated.

    Regards,

    Stan

  • Stan,

    Okay) But... A few days ago I managed it. I made simple block write operations (not Write Protect). So how do you expalin it?

    According to those facts it's so strange.

    Well, I'll try to do Write Protect operations

  • Ivan,

    It was only my supposition. It was because you were waiting for write operation to complete and this never happened (your initial post) . I can't really say what could be the exact issue.

  • Hi, Stan

    I'll try to describe how I wrote a data to SD card occasionally (before I asked about this problem on this thread)

    Procedure of writing consist of some steps (generally):
    (1) preparing BWR bits in MMC_IE register
    -> (2) sending command with CMD line
    -> (3) waiting for BWE in MMC_STAT register
    -> (4) sending data.

    So, this function hasn't worked, but... When I've set a breakpoint between steps (1) and (2) it has worked. 
    After this actions I repeated this function without breakpoint and it still worked. 

    When I restarted the TDA3 device then, I needed to repeat the operation with breakpoint. 

    Then I decided to make reading function. I tested it and then my writing function started to work incorrectly (and it's not working now)

    How can the breakpoint actions affect the writing function?

  • I've just tried to do a write protect operations

    So, as I see in SD Spec Part1, both SDHC and SDXC cards don't support Write Protect operations.

    In accroding to these words I've just checked Write Prot. operations and SD card doesn't respond to these commands

  • > How can the breakpoint actions affect the writing function?

    This is often because a hardware (SDIO controller) is needing some time to complete a certain function but software proceeds to next  function too early (e.g. SW is not polling for a register bit to toggle). If you insert a breakpoint in your code, then the software is paused, leaving to hardware a very long timeframe to complete its task before you decide to click to continue execution.

  • Stan,

    I still don't understand something.

    You said: SD/MMC memory cards are not supported.

    But sometimes writing operations ended successfully after breakponits, but SW polled all needed flags in status register

    Where is the mistake...

    In addition to this - write protect operations aren't supported by SDHC and SDXC cards

    Well, I've searched some examples in PDK driver and CSL, so... mostly my SW consist of functions from those libraries and patterns.

  • Hi, Stan

    I work with evaluation board (I've forgot to notice that, maybe it's famous)

    But
    I've found the mistake!

    As you see on the picture I need to poll BWR bit in MMC_STAT register to write data into the buffer. But this bit is always zero after preparing BWR bit in MMC_IE register and sending CMD.

    In according to reference manual, after I sent CMD, both WTA bit and BWE bit became 1 in MMC_PSTATE

    But BWR bit in MMC_STAT is still 0.
    When I learnt the examples from PDK driver I saw that SW polls the BWR bit MMC_STAT too.

    So, I decided to poll BWE bit in MMC_PSTATE (instead of BWR bit in MMC_STAT) and it started to work. It really works!

    Is there a mistake in reference manual or/and in PDK?

  • Hi Ivan,

    Glad to hear you made writes working!

    The reason you are seeing BWR always 0 could be bacause the controller is being configured to DMA mode. See the following note in the TRM:

    Buffer write ready

    Note: If the DMA transmit mode is enabled, this bit is
    never set; instead, a DMA transmit request to the main
    DMA controller of the system is generated.

    Typically, such peripherals are being used in DMA mode, therefore it could be, the MMC driver has configured the SDIO module to DMA, during init.

    Regards,

    Stan

  • Stan,

    I've just checked the configuration of SDIO controller. So, SDIO controller isn't in DMA mode.

    Maybe I could miss something, but I didn't configure DMA mode in SDIO controller, and all the bits in SDIO controller registers which related to DMA mode are zeros.

    Have you ever had any issues like this? I ask you because I haven't found it before.

  • Hi Ivan,

    It is quite possible this is a documentation error in the flow diagram. Perhaps because polling method is rarely used, no one had noticed. I will work with TRM team to see how to fix this.

    thanks,

    Stan