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

OMAP3530 MMC3 command abort

Vedat Hallac
Prodigy 20 points
Other Parts Discussed in Thread: OMAP3530

Hi,

We are trying to talk to a Marvell 88W8688 over MMC3 with an OMAP3530. The wifi module is configured to use 1,8V for its host I/O. After spending a week, trying to get the MMC to do anything but timeout, we changed the MMC3_CLK mux to have input enabled (see http://www.mail-archive.com/linux-omap@vger.kernel.org/msg14959.html ), and there was some difference: any command we try to send stops after 5 clock cycles, and the MMCHS_STAT is set to 0x00038000 (CCRC, CTO, ERRI). We tried the standard linux MMC/SDIO detection code (starts with CMD0, follows up with a CMD8, and a CMD5), and modified u-boot code to send only SDIO commands (well, CMD5, ARG=0, to be exact). All commands fail the same way.

The Technical Reference Manual says that this occurs when a command is aborted because of a contention on the CMD line, but the signal on the CMD wire looks clean and correct (we get 01000 for a CMD5, the clock stops at the falling edge of the last 0, and the CMD line slowly rises a bit later) until OMAP decides to abort the operation. I found no other references to this particular situation anywhere. Did anyone else have a similar issue, or does anyone know anything about what may trigger a CMD line contention when the CMD line looks OK?

Kind regards,

Vedat Hallac

  • 0
    Intellectual 955 points

    Vedat Hallac,

       Were you able to find the reason why the MMC CMD Line contention occurs?

       Am facing the same issue here.

     

     

     Please advice.

     

     

    Regards,

    sriram

     

     

     

  • 0 in reply to Sriram V
    TI__Guru* 86180 points

    Check the MMC_CLK signal as well.  We recommend putting a series resistor (around 33ohm) on the clock line, close to OMAP, to reduce reflections on the line.  It is used to retime any receive data, and reflections may be the reason why it is falsely registering contention on CMD.

    Regards,

    james

     

  • 0 in reply to Sriram V
    Prodigy 20 points

    Hi Sriram,

    We were able to fix the issue. I believe it was a combination of hardware and software issues. As part of the hardware fixes, we've added the series resistor to the CLK line as per JJD's instructions. However, I believe we were not driving the WiFi module correctly, and there is a chance it was pulling some  of the SDIO lines low. Unfortunately, I was never able to learn exactly what was fixed on the hardware side of things.

    For the software part, we were using a 2.6.29 kernel, which had quite a number of MMC problems. The most important issue was the setting of OMAP2_MMCSDIO2ADPCLKISEL bit in the control register. The kernel we used only had the code to set it when needed, but didn't clear it when configured for external clock. Also, the code in question (twl_mmc23_set_power function in arch/arm/mach-omap2/mmc-twl4030.c) didn't even get executed if there is no regulator connected to the MMC port (we provided a fixed power, so there were no regulators involved).

    In addition, we've moved to MMC3 on a different hardware, and the driver (drivers/mmc/host/omap_hsmmc.c) cannot handle MMC3 at all - there are some patches to add the DMA setup for the third port - I suspect this is not your problem, but better be safe and double check it. There were other minor fixes and changes we've made for the MMC (mostly patches I found with google, and selected the ones that seemed relevant), but I don't think any of these contributed to the fix of this problem.

    Good luck in solving the issues.

    Best regards,

    Vedat Hallac