Jump to content

SD communication electrical considerations

Recommended Posts

*** This is educational material only concerning current limits and their effects on things like rise and fall times, and how they can theoretically impact SD cards.  The correlation with reality is purely theoretical and has not been empirically proven, the concept is correct but any specific values may be/ probably are off by some factor***


A lot of boards from various vendors inevitably have some difficulties with electrical signalling.  You see it in delay values, phase correction in software, etc.  The general prevailing theory is almost always "get it close and fix it in software".  But, the software team is not always clued in, or the physical reality is simply not able to be fixed that way.  Today I'll go into SD cards and the need for proper signal paths, limited capacitance along the way, and proper drive levels at the SoC.


This came to my attention while reviewing failures to boot on RK3328 devices, and while this particular issue may still be independent (no root cause confirmed as yet), I have a suspicion it is at least a contributing factor.


GPIO's on SoC's have, typically, current limiting on each pin or bank of pins.  For Rockchip, this limit defaults to 4mA, with 8 and 12 being available as optional settings.  This includes the SD card bus, clock, output, etc.  These current limits are exactly that, limits.  If the interface only needs 1 mA, it will only pull 1 mA, regardless of the GPIO drive setting.  if it needs more, however, it will only get what the drive setting allows.


SD card interface standards have 3 voltage signalling modes, SBC's only make use of 1 or 2 of them.  Many boards supply only 3.3V to the card, limiting to frequencies of 25 or 50 MHz.  Those that support UHS-I modes allow 1.8V signalling, and the range of speeds there include the original 25 and 50 MHz, but add higher speeds as well (100 and 208).  The higher speeds absolutely require the lower voltage, though the 25 and 50 Mhz speeds benefit from it as well due to improvements in rise/fall time with the smaller voltage transitions.


The SD standard requires a total line capacitance of 40 pF or less on each line, including the internals of the card.  I will simply assume 40 pF for the simulations, as it's likely few if any of these boards are "optimal" in that regard.


I'll be using LTSpice as an aid to show the effects of the current limitations, measuring voltage across the capacitance.  In reality there would be a complex impedance with the resistance I'm not modelling and the capacitance distributed throughout the system, which would cause some slightly different behavior.  This is mostly an educational introduction to the scary universe of high-frequency switching, so I'll skip the really gory details for the sake of readability.  In this circuit the LimiterDiode does exactly that, it limits current.




With a 4 mA limit into a 40 pF load at 3.3 Volts, 50 MHz, the signal is unusable.  Top in blue is the current sourced by the supply, stuck at the 4 mA limit at all times, below in red is the desired waveform, in green the result.




The board will crash if it attempts this.  Now, you might say, what if the board is extremely well made and the capacitance is lower?


Well, it looks like this (assuming 20 pF, which may not really be possible):




Still, no hope of operating properly.  Dropping to 25 MHz has roughly the same effect.  As I said, this is worst case, so don't jump down my throat about your board with the limits working at 4mA.  I am also assuming 4 mA source and sink limits, it may not be symmetrical, in which case the shape goes from triangle to shark fin.  Cutting the voltage almost in half by going to UHS-I signalling levels has the same effect (ratio wise vs the V_High value) as cutting the capacitance down.


On the ASUS tinker board this was discovered at some point, and the current limits increased to 8 mA.  I have not tried a card with no UHS support at 50 MHz (at least to my knowledge), the results at 3.3V/50MHz still look bad in my oversimplification, much like cutting voltage in half or capacitance or frequency, again, they all play into the same charge rate/time constant




At 25 MHz, however, 8 mA is far more reasonable:



Now to the big reason for 1.8 V signalling:



50 MHz, 1.8V, 40 pF, 8 mA drive.


Assumptions:  source/sink values both controlled.  It's possible this is not the case.  If there is no "sink" limit, or if you assume 20 mA sink limit:



3.3V signalling, 50 MHz, 40 pF load, 8 mA source, 20 mA sink:



Now, as a final bit, assume there were no current limits of any kind, and let's measure what the system would need to supply at 50 MHz 3.3V:



So 120 mA or so to create the exact waveform, assuming some sort of simulated resistance somewhere in the system (in reality there would be a measurable resistance and therefor a current lower than 120, but also a longer rise and fall time)  Needless to say, a lot more than 4.


This is mostly important for boards that do not implement the 1.8V signalling modes, but do have aggressive current limiting on the SD card I/O's.  50 MHz is a bad place to live at 3.3 volts given a mechanical connector with wide flat terminals, and routing that doesn't always get as much care as maybe it deserves.  RPI, a board with these issues, seems able to source/sink 16 mA, most likely accounting for it's ability (when not starving itself for power, cooking itself, etc) to be "overclocked" in highspeed 3.3V mode.  Rockchip can only push 12 mA, I haven't read up on Amlogic yet, so you can't expect to have the same performance if you're not willing to add the necessary support for 1.8V signalling.


Link to comment
Share on other sites

Help Armbian team helping you

Quick follow-up, my board / SD card combinations don't exhibit issues, but having access to @JMCC's misfortune in having a Renegade with constant file system corruption/failures, I took advantage.  A series of testing on his part using an 8mA drive setting on the RK3328 (so far) solved his issue, and in any case significantly improved the situation, I've pushed a patch for that to the build system so we can get a wider sample.  Again, as I said, the increase doesn't "force" anything to take power it can't handle, it simply makes it available if needed.  A lot more work in that area is needed, such as re-enabling UHS modes on boards with hardware support for the voltage level switching

Link to comment
Share on other sites

Nice info!  On a side note, it makes me wonder if anyone having problems with RFI, especially on gpio pins etc.


Wonder if the random selection of switching wall-warts usually powering our sbc's have no idea what rfi filtering - either in or out - is, and how it may be affecting things.  Maybe testing the noise floor against a linear supply might be fun.


I know for my ham radio stuff, I usually have to incorporate ferrite materials not only on the output leads, but also prevent the warts from getting back into the house and/or each other with something like a Tripp-Lite Isobar for the ac outlets.


Currently testing:  I applied Deoxit-D5 with a q-tip to my sd card contacts, and while wet exercised the jack with a few insertions, waited about 30 seconds and wiped it off with a rag.  Yay - it still boots!


I'll let you know if I wake up to a rubber stick of gum in the morning, or if it falls apart shortly... :)


Link to comment
Share on other sites

16 hours ago, PDP11 said:

On a side note, it makes me wonder if anyone having problems with RFI, especially on gpio pins etc.


Probably a good question, are you concerned about emissions from the SBC or immunity of the SBC to outside noises?  Obviously increasing drive levels makes the square waves more square, meaning higher frequency content.  For immunity, my guess is conducted immunity through the power supply is a touchy spot, being supplied 5 V and running on 5V, no chance to avoid noise.

Link to comment
Share on other sites

Noise has only been an issue sometimes when running high-power rf getting into the gpio line cabling making it go deaf or garbled data.  Fixed with ferrites, but the sd card and sbc itself stayed alive.



Link to comment
Share on other sites

This topic is now closed to further replies.

  • Create New...