4
\$\begingroup\$

I've been trying to hook up an eMMC chip to a FPGA, that receives commands via a micro-controller to initialize and trigger write/read operations on given sectors.

I'm having trouble with the boot sequence of the MMC I'm using, I'm following the standards that you'll find here or here if you don't want to create an account on JEDEC. The document is rather dense and I'm a bit confused. This is what I do for now:

  1. Startup: MMC is clocked, CMD line is pulled down
  2. On user action, send CMD0 0x00 through CMD, it's a 48bits wide command built like this: cmd <= "01" & CMD0 & STUFF_BITS32 & "1001010" & '1'; (See p145/352 of the pdf file above). This is the GO_IDLE_STATE command. No response expected.
  3. On user action, send CMD1 0x80FF8080. Built like the previous command, except CRC7 is 0010110. This is SEND_OP_COND command, which should send back data through the CMD line.
  4. On user action, send CMD2 0x00. Built like the previous command, except CRC7 is 1100001. This is ALL_SEND_CID command, which should send back data through the CMD line.

Problem is, I don't get any data in. Any idea on what I'm doing wrong?

See below for captures from a logic analyzer; Sending CMD0 Sending CMD1

Additional info: For now I've wired a Transcend MMCPlus 1GB card, following the pinouts I've found online. I have not connected the data lines yet. I'm calculating the CRC7 with the info provided on p.254/352 (8.2.1). The MMC Clock is divided from my 12MHz on-chip clock 32 times, making it ~375kHz for now (planning on speeding it up after initialization succeeds)

\$\endgroup\$

2 Answers 2

Reset to default
3
\$\begingroup\$

I have the same issue though the host is ARM MPU. However, I believe CMD line should be pulled up by default, as my eMMC design guide states:

"RCMD_PU:A 10K ohm pull-up resistor should be connected to the CMD signal to prevent bus floating."

\$\endgroup\$
7
  • \$\begingroup\$ You are absolutely right, pulling CMD down at start for long enough toggles a different boot operation. I had to add this into the constraints of my design and it's responding now \$\endgroup\$
    – Fluffy
    Commented Jun 30, 2016 at 8:09
  • \$\begingroup\$ I am still having issue (no response for CMD1). Could you help post my question to ks0ze as I am unable to comment under his response? I am using 8GB eMMC w/ both power and bus operated at 3.3V, and no 1.8V. In that case, shall the CMD1 payload be C0FF8000 instead of C0FF8080, as bit [7] of OCR for 1.8V is not available? Thank you! \$\endgroup\$
    – user115384
    Commented Jun 30, 2016 at 19:59
  • \$\begingroup\$ Either way, you should get a response from the eMMC. I've found myself trying with 0x0000 as argument for CMD1, and the eMMC still responds in my current setup. The busy bit stays low, which is wrong, but it's communicating. However, it will remain silent if you send the wrong CRC with your command (which is kind of stupid imo) \$\endgroup\$
    – Fluffy
    Commented Jul 1, 2016 at 11:37
  • 1
    \$\begingroup\$ I got it work now. The reason is I didn't issue CMD0 before sending CMD1, though I still don't understand as A.6.1 doesn't mention that. Anyway, thank you! \$\endgroup\$
    – user115384
    Commented Jul 1, 2016 at 18:44
  • 1
    \$\begingroup\$ @Pikrass It's been a while indeed :D The bga socket I was using was faulty, I used another one with the exact same wiring and it ended up working right away. Further analysis showed a badly printed power line on the PCB. From what I recall the eMMC lowered its busy bit after 3 or 4 CMD1 requests \$\endgroup\$
    – Fluffy
    Commented Sep 26, 2019 at 14:36
3
\$\begingroup\$

CMD 1 is supposed to have the OCR Code with out the busy bit as the 32bit payload. You should be sending

cmd <="01" & "000001" & x"80FF8080" & "0010110" & '1';

according to section A.6.1 for chips with capacity less than or equal to 2GB and

cmd <="01" & "000001" & x"C0FF8080" & "1011111" & '1';

for chips greater than 2GB.

\$\endgroup\$
6
  • \$\begingroup\$ As a side note, if you don't need high speed operation I would highly recommend using an SD card in SPI mode over eMMC because I've gone through the process of implementing a HS400 capable controller and it is quite painful. \$\endgroup\$
    – ks0ze
    Commented Jun 28, 2016 at 14:49
  • \$\begingroup\$ Thank you for pointing that out, I did not see that info! The documentation is really dense. Sadly it doesn't solve my issue, still no response. I'm adding capture from my logic analyzer, maybe I'm missing something. \$\endgroup\$
    – Fluffy
    Commented Jun 29, 2016 at 14:21
  • \$\begingroup\$ @Fluff'n'Stuff There is a 1 millisecond + 74 clock cycle start up delay before you should be sending any commands. Also, verify the command line is set to high impedance (Z) after sending the command. \$\endgroup\$
    – ks0ze
    Commented Jun 29, 2016 at 19:15
  • \$\begingroup\$ Thank you very much, it was pretty much a combination of all those things, had the wrong command, cmd wasn't pulled up correctly.. I get a response now, although it's not the right one; 0x00ff8080. But I'm getting there! \$\endgroup\$
    – Fluffy
    Commented Jun 30, 2016 at 8:11
  • \$\begingroup\$ Once again, going back to A.6.1 if you get 0x00ff8080 as a response for your 1GB card you just repeat CMD1 until the response comes back as 0x80FF8080. For the eMMC chip you will be expecting 0x40FF8080 as the "Busy" response and when the chip becomes not busy you will get 0xC0FF8080 \$\endgroup\$
    – ks0ze
    Commented Jun 30, 2016 at 12:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.