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.

AM3358: MMC Controller R1b response

Part Number: AM3358

It seems to me that AM3358 MMC controller does not generate interrupt on end of busy state of R1b response.

For example, for command CMD6 (MMC), it generates CC (command completion) interrupt on response,

but the card is still busy (dat0 is low).

Are there any method to detect end of busy state of R1b response other than polling programmatically?

Are there any difference of behavior between SD_CMD.RSP_TYPE == 0x2 (R1) and 0x3 (R1b) ?

Regards.

  • I will try to find someone that can answer your question. However, it may be helpful if you can provide some details related to your system. Which AM335x port and what software platform is being used in your system?

    Regards,
    Paul
  • Thank you.

    The board is Beagle Bone Black .

    Sitara AM3358BZCZ100, 1GHZ, processor .

    4GB eMMC is connected via MMC1 port.

    No operating system (so called "Bare Metal").

    Everything is working fine on both microSD (MMC0 port) and eMMC (MMC1 port).

     

    Regards.

     

  • I'm not an expert on the eMMC protocol, so not sure this will be helpful.

    I was reviewing the interrupts discussed in the MMC chapter of the TRM and there is one that sounds promising. Event flag "SD_STAT[1] TC says "In write mode, this bit is automatically set on completion of the DAT line use (SD_PSTATE[2] DLA)." Can you use this to generate an interrupt when the transfer is complete?

    We typically do not support questions related to bare metal software development and suggest customers reference our two software platforms, Linux and RTOS. Have you looked to see how this is being handled in the software provided by TI?

    Regards,
    Paul
  • Thank you.
    I understand "Bare Metal" is not supported.
    I found an interesting comment in Linux driver file "omap_hsmmc.c".
    -------------------------------------------------
    void omap_hsmmc_xfer_done()
    /* TC before CC from CMD6 - don't know why, but it happens */
    -------------------------------------------------

    I will further investigate.


    For SD_PSTATE[2] DLA, it seems to me this flag is related to data transfer.
    MMC CMD6 does not have data transfer (command and response + busy only).


    Regards.