• 0
sy2002

Enough Current to Drive microSDHC on a Nexys 4 DDR?

Question

Hi all,

I am using a Nexys 4 DDR board to interface microSD and microSDHC cards using the SPI mode. (For those interested in what the whole thing is all about, click here.)

Might it be, that microSD cards are needing current in the range of 10mA (e.g. look at Transcend's 2GB SD card datasheet - link) and microSDHC (SDHC vs SD) are needing 10x of this, e.g. look here at Samsung's 32GB SDHC card:

http://www.singerphoto.co.za/SingerPhotographicOnlineDocuments/WebImages/SellSheetPDFs/mesamp64a.pdf

How much current is the Nexys 4 DDR SD Card slot able to supply?

The first card I wrote about above (Transcend's 2GB SD V2 card) works fine with my controller, the second card (Samsung's) is not even initializing (no response to CMD0).  (Some other SDHC cards are working with my controller, see below.)

Are there some settings I need to do in the UCF file, e.g. fast SLEW rate or another value for DRIVE (to supply more current)?

Currently my UCF file looks like this:

##Micro SD Connector
NET "SD_RESET"             LOC = E2  | IOSTANDARD = LVCMOS33;
NET "SD_CLK"               LOC = B1  | IOSTANDARD = LVCMOS33;
NET "SD_MOSI"              LOC = C1  | IOSTANDARD = LVCMOS33;
NET "SD_MISO"              LOC = C2  | IOSTANDARD = LVCMOS33 | PULLUP;

Here is the source (Link) of my controller. I tested it with ~40 cards. 20 of them are SD cards Version 1 and Version 2 (from 64 MB up to two GB): Works fine and stable with all of them. 20 of them are SDHC. When it comes to SDHC, it works with about 50% of the cards (well - works kind of: I need to reset after each read command). The other 50% are showing really strange behaviours: Some are only reporting themselves as a SDHC during the coldstart/hard reset (insert card) and from then on "claim" to be a SD V2 card, others are initializing well but when it comes to reading, they never send a R1 on READ_BLOCK, etc. While googling I found some comments in forums, that strange behaviour might be rooted in a lack of current, so this is the background of my question.

Best regards

  Mirko

 

 

 

Share this post


Link to post
Share on other sites

5 answers to this question

Recommended Posts

  • 1

@sy2002,

I would be quite surprised if the FPGA is driving the power of the SD Card at all!  The IO ports on the card are not suitable for power supplies. 

If you look at a full-size SD memory card, there are 8 wires in a line, numbered one to eight from the left corner with the diagonal on it to the right, and a ninth wire offset from the others in the diagonal area.  Of these wires, wire 4 is supposed to be connected to power, 3 and 6 to ground.  These are not the FPGA I/O pins at all, but rather just a part of a functioning card interface.  The micro SD cards are similar, save two exceptions.  The first is that there are only eight pins, and hence there's only one power and one ground pin.  The second exception is that my SD card manual doesn't show a picture of them.  :P   Further, in proper protocol fashion, all four of the data lines are supposed to have pull up resistors (this includes the chip select SD_DAT3, as well as SD_DAT0/MISO), and the same with the command line (SD_CMD/MOSI).  Finally, when I examine the Nexys 4 DDR schematic, I find this to be how the Nexys is wired.  (Well done, Digilent!  :D)  Further, if you look at the SD_RESET wire, it simply controls a transistor determining whether or not mains power is fed to the micro SD card or not.  Hence asserting the RESET control is the same as pulling power from the card (highly discouraged when the card is in operation, since it can lead to unrecoverable bad sectors ...)

Thus, increasing the drive strength on the I/O wires will do nothing to power your SD card.

Plugging your board into a wall power supply, on the other hand, will do everything to power your SD card.

If you are concerned at all about the on-board power supply, I would consider looking into the XADC functionality of the Artix chip to see if you can measure the power supply voltage, and the current usage, and to see whether or not the power is indeed dropping during the times you think it is.

Just my two cents, and I hope this helps,

Dan

Share this post


Link to post
Share on other sites
  • 0

Hi Mirko,

If you haven't already,  using an external power supply might resolve your current issue. You can also add slew and drive to the constraints like

# NET "SRAM_ADDR[0]" LOC = D20 | IOSTANDARD = LVCMOS33 | SLEW = FAST | DRIVE = 4 ;

not sure what value drive should be set to. More information about drive can be found here.

Thank you,

Jon

Edited by jpeyron

Share this post


Link to post
Share on other sites
  • 0

Hi Jon,

thank you for your feedback!

I already experimented with larger drive values (I even tried switching from LVCMOS33 to LVTTL, because there, DRIVE can go as high as 24, whereas it can be only 16 as a maximum, whenusing LVCMOS33). Unfortunatelly all this did not help.

Do you know by chance, if inside Nexys' SD card reader is some kind of a "driver" IC that utilizes external power - or - if the FPGA is driving the SD card directly?

Best regards

  Mirko

Share this post


Link to post
Share on other sites
  • 0

Hi @D@n,

thank you very much for your detailed answer and thank you for looking into the Nexys 4 DDR schematic.

Currently I am operating the board using the USB port of my Mac. It worked with "everything" so far, so it took me a while even thinking that the problem might be tied to current. But the SDHC cards which are showing this random erroneous behaviour are kind of "smelling" like a current problem.

=> Now having read your post, I will go and buy myself a wall power supply, test again and report back in this forum.

About the reset line controlling if mains power is fed into the card: This is *very* interessting indeed! Because the card stays in the SPI mode also after asserting the RESET control. But if I "manually" power cycle the card, i.e. removing it from the reader and putting it back in again, then it is in native mode and I need to switch it back to SPI. So are you sure about this "asserting RESET is equivalent to taking power away"? (Talking about Nexys' microSD card reader.)

Here is a diagram, that shows the microSD wiring:

http://elm-chan.org/docs/mmc/gfx1/sdmm_contact.jpeg

The CS (aka RESET) is connected to a line called CAT3 and VCC seems separate.

Sorry, if my questions seem stupid - I am a beginner - and I am just wondering, why a lot of people (not only me in my code (LINK)) are asserting the reset line pretty regularly after sending any SPI CMD to the card. Do I mix up things here?

One small other detail: If I get you right, I can change this line in my UCF file:

NET "SD_MISO"              LOC = C2  | IOSTANDARD = LVCMOS33 | PULLUP;

to this line

NET "SD_MISO"              LOC = C2  | IOSTANDARD = LVCMOS33;

because the Nexys 4 DDR's microSD card reader already is wired in a way that the pull-ups are there and I do not need to use the FPGA's internal pull-ups, right?
 

Thanks again and best regards

  Mirko

 

Share this post


Link to post
Share on other sites
  • 0

@sy2002, Mirko,

For reference, here's where you can find the Nexys 4 DDR schematic, and Wikipedia has a wonderful page describing SD cards.  On that page, you will find a better diagram of pinouts for the micro SD cards.  The diagram you link to above is to an older protocol, the MMC protocol.  Judging by the diagram (and the diagram you link to above), MMC cards were about the size of SD cards.  MicroSD cards are much smaller.  The other difference you may notice is that microSD cards have two longer pins, pins 4 and 6.  These are the power and ground pins respectively--at least according to the wikipedia page.  :D

That said, you should notice that there are no "reset" pins on the card.  :o  If you are interested in how the reset wire gets to the chip, you'll want to look at location C3 on page 2 of the Nexys DDR schematic.  So ... why didn't the card completely reset when you asserted it?  Good question.  Obviously, by design, it should have.  So ... what went wrong?  My first thought was that the I/O pins unintentially provided the current supply, but looking at the schematic Digilent has done a good job connecting the pull ups on those pins to the power that would've also been pulled to ground.  My second guess is that you started trying to power it from the FPGA's data lines.  I'm going to wager that, internal to the chip, the various data lines are connected to a resistor and then the internal microSD power bus.  Hence, if you don't pull all the data wires to zero while asserting reset, you haven't accomplished a full reset.  This now means that your FPGA is being turned into a power supply, and it is likely going to either draw power away from your design (causing inexplicable hiccups), or perhaps just from the other pins on that bank.  Alternatively, the C191 capacitor, or some internal capacitance, might hold enough current to power the card for ... how long were you pulling reset down for?

At any rate, I wouldn't recommend using the reset as part of your protocol.  :)  I'm really not sure what others were referring to when they claimed to be asserting the reset line.  I have never used "reset" as part of any communication I've done with SD cards.  If you need to start your protocol interaction with the chip over from scratch, then go ahead and pull the reset wire to ground in addition to all of the other SD pins.

As to your last question, yes, you should be able to remove the pull up lines from your UCF file.

And, as an aside and in case you are interested, you can find the work I've done with SD cards posted here.  You might find it as a valuable example to work from, you might find it too confusing for your taste (there was a *lot* of logic going on), your call.  Perhaps you are just interested in the SD card simulator that I used to test my core with before connecting it to the card.  (The core should work still with both simulation and card ...)  My biggest disappointment with my own controller is that it has no way of supporting either multiple block write or multiple block read commands due to the structure of how I set the controller up.  Still, you might find the controller, simulator, and/or the documentation for it useful.

Dan

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now