SD card/SDIO 3.0 level translation solution

[asmi]

I'm working on adding SD/SDIO card slot to my FPGA board, but there is a problem - UHS-I cards require switching from 3.3V to 1.8 V logic level during the course of work in order to get maximum performance out of cards. As changing IO standard on a fly is not possible, the only solution is some sort of level translator. Unfortunately the only solution I've found in stock (IP4856CX25) is 0.4 mm pitch BGA which require microvias and raises the price of a board to a stratosphere. So I wonder if anybody over here has any solution for this problem.

[sd]

http://www.ti.com/lit/ds/symlink/txs02612.pdf

[asmi]

http://www.ti.com/lit/ds/symlink/txs02612.pdf

This one is only rated to 60 MHz, while SDR104 requires 208 MHz clock, so it's not SD3.0 compliant and can't get full UHS-I throughput. Some other TI parts like SN74AVCA406 are also no good as they are rated up to 95 MHz.
The only solution I can think of right now would be to use 1.8V logic standard on FPGA, but then use hi-bandwidth analog switch (like TS3A27518) to switch in 1.8->3.3 V voltage translator during boot-up when 3.3V signalling is required, but switch it off to straight-through connection to FPGA once the bus is switched to 1.8 V. Since SD boot sequence until bus voltage switch is short and no high frequency is required, I can get away with pretty much any translator as long as channel-to-channel skew won't be too large,

[mark03]

As I hope to design an I.MX RT10xx board in the near future, and these MCUs claim to support UHS-I, I was curious how NXP handled this on their eval board.  Turns out they have a separate VCC for the IO bank containing the SD signals, and this rail comes from an adjustable regulator which they switch between 1.8 and 3.3 volts on the fly.

I am a rank beginner with FPGAs.  What happens if you define the IO standard as LVCMOS 3.3 and then step VCCO for that IO bank down to 1.8V?  What does switching the IO standard between LVCMOS 1.8/2.5/3.3 actually *do*, physically?

[Marco]

I have no idea how to do it smart ... but I have an idea how to do it expensively.

Connect the SD-connector to something like a MAX4996 and then to slow level converter to do communication at HS, then when it switches SDR104 switch to a separate set of pins on your FPGA with the MAX4996. Needs extra pins on the FPGA, but only one IO voltage.

[asmi]

I am a rank beginner with FPGAs.  What happens if you define the IO standard as LVCMOS 3.3 and then step VCCO for that IO bank down to 1.8V?  What does switching the IO standard between LVCMOS 1.8/2.5/3.3 actually *do*, physically?

FPGA I/O blocks have different drivers for different standards. Besides since the bank has 50 I/O pins and SD interface only uses 6, I will have to solve reverse problem for other 44 pins, which don't need such voltage shenanigans

[asmi]

I have no idea how to do it smart ... but I have an idea how to do it expensively.

Connect the SD-connector to something like a MAX4996 and then to slow level converter to do communication at HS, then when it switches SDR104 switch to a separate set of pins on your FPGA with the MAX4996. Needs extra pins on the FPGA, but only one IO voltage.

That's essentially what I've proposed in my first reply, except since there is already voltage converter, you might as well reuse same pins as you will never have to use them both at the same time. The good thing about TS3A27518 switch is that it's got 6 SPDT switches which is exactly how much I need.

[Marco]

Oh, didn't see that. Capacitive load of the TS3A27518 is high though ... it pushes you past the recommendations of parasitic capacitance all on it's own. With wide traces (ie. lower impedance) and a smaller series resistance than normal you might be able to get away with it, but with MAX4996 you wouldn't have to go that far (6 pF).

[asmi]

Oh, didn't see that. Capacitive load of the TS3A27518 is high though ... it pushes you past the recommendations of parasitic capacitance all on it's own. With wide traces (ie. lower impedance) and a smaller series resistance than normal you might be able to get away with it, but with MAX4996 you wouldn't have to go that far (6 pF).

I don't like that I will need two MAX4996 ICs, which can introduce bus skew, also they are quite expensive Will see if I will be able to find any other switch with low enough bus loading.

[asmi]

Looks like I've found the right switch! It's TS3DDR4000. I bit of an overkill as I only need 6 lines, and the specs are way above and beyond, but - hey - it's still cheaper than MAX4996!

[Marco]

Nice find, not something I would have thought to look at.

[asmi]

Another thing I realized after reading SD spec is that I can get away with only single bit bidirectional voltage translator + one unidirectional one (for clock) as all commands required to switch to 1.8V don't require any data transfers over DAT lines.

[thobie]

Yeah, struggling with the same idiotic implementation problem with microsd card interface - and the LVS ”low voltage signaling” cards are not yet here unfortunately. Anyone tried how the modern UHS-I cards behave supplied with just between 1.8V and 2.7V?

Even Xilinx is using in their development boards some silly 60USD adapter spcaer PCB to get the 0.4mm BGA to work.  What FPGA are you using? Planned to do this for Xilinx Zynq Ultrascale+.

I was already going to use discrete >200MHz level translators from TI, good to know that if initialization/level change to 1.8v is done in SPI mode, not all lines are used. But why only two level translators - or one of those bi-directional not uni? Controller to card data input level 1.8V could be in the range of ”high” signal if card supplied with 2.7V, so could get without level translation. Data from card to controller with unidirectional translator? Clock could survive without translation when AC coupled, haven’t done the math is it so also in practice.

[asmi]

Yeah, struggling with the same idiotic implementation problem with microsd card interface - and the LVS ”low voltage signaling” cards are not yet here unfortunately. Anyone tried how the modern UHS-I cards behave supplied with just between 1.8V and 2.7V?

Yea I've never seen any LV cards "in the wild", which would actually be good enough for my needs.

Even Xilinx is using in their development boards some silly 60USD adapter spcaer PCB to get the 0.4mm BGA to work.  What FPGA are you using? Planned to do this for Xilinx Zynq Ultrascale+.

I plan to use it with 7 series FPGAs. There are several projects where I need this in both microSD and full-size SDIO format. I'm currently investigating how much would it cost for me to make such module, and I will also need to figure out how to get good enough SI as 208 MHz is a no joke. If the price will be good, maybe I will put up a Kickstarter campaign or something to get it out in the wild, as larger batch will means lower per-unit price.

I was already going to use discrete >200MHz level translators from TI, good to know that if initialization/level change to 1.8v is done in SPI mode, not all lines are used. But why only two level translators - or one of those bi-directional not uni? Controller to card data input level 1.8V could be in the range of ”high” signal if card supplied with 2.7V, so could get without level translation. Data from card to controller with unidirectional translator? Clock could survive without translation when AC coupled, haven’t done the math is it so also in practice.

SD spec says startup clock can be as low as 400 kHz, so AC-coupling is not going to work.
As for the shortest path to 1.8V - all data exchange is done over CMD line - so bidirectional translator is needed here, and another unidirectional one is for clock. There is a nice command sequence diagram in the spec to get into 1.8V, and none of commands mentioned there do any data exchange over data lines. Finally, 1.8V mode only works in 4-bit mode (over all data lines).
Also SPI is not available in 1.8V mode and once 1.8V is turned on, the only way to turn it off (so that SPI could be re-enabled) is to power-cycle the card.

[mark03]

I had occasion to come back to this question today, and had a wild (and potentially stupid) idea:

The STM32H7 I am looking at does not have > 1 independent IO bank, however the IO rail is separate from the core, DCDC input, etc.  You can probably see where this is going...

If
(1) sleep current on the SD card is acceptable (usually less than 500 uA from what I understand),
(2) the application can require the SD card to be present at power up, and
(3) 1.8V is a satisfactory IO standard for everything else connected to the MCU,
then in principle you can design a switchable 3.3/1.8 VDD and supply it to both the card and the MCU.  Immediately after MCU reset, VDD=3.3V.  Perform the card initialization and voltage change while all of the other IOs are still tri-stated.  Then, switch the VDD rail to 1.8V and proceed to configure other GPIOs/peripherals, everyone operating harmoniously at 1.8V.

Alternatively, does anyone have an up-to-date recipe for doing the proper level translation without relying on chip-scale BGAs with 0.4mm pitch?

[bugnate]

Yea I've never seen any LV cards "in the wild", which would actually be good enough for my needs.

I had thought that LVS support was implied with A2 standard, which is more or less available, no?
EDIT: Just looked at the timestamps. D'oh.

[mark03]

EDIT: Just looked at the timestamps. D'oh.

Yeah, sorry if that caught someone off guard.  OTOH, the question posed by the thread is still very much current and open, so...

If a nontrivial fraction of new SD cards actually don't need the voltage switching dance, that would be news to me.  Very welcome news.

[mark03]

I did some more digging, and found that yes, indeed "A2" implies "LVS".  A2 cards are still not very common, but they are starting to appear.  Unfortunately, this has only led to more questions:

The SD spec does not discuss LVS directly; instead it refers to a "Low Voltage Interface Addendum" which has not leaked out online.  If you google it you will find some conversations by Linux kernel developers attempting to figure out why A2 cards are breaking certain hardware, and that's about it.  Anyway, if the writing style of that addendum is anything like that of the main SD spec, reading it may not help much

On the kernel mailing list they concluded that LVS only lets you start *communication* at 1.8V; according to this view, the card must still be supplied with 3.3V power until it is negotiated to 1.8V.  That seems odd, but it's the only interpretation I've been able to find by someone who actually read the spec.  At least it would solve the bus voltage translation issue.

Then there is this from the SD Association marketeers:

LVS cards are designed to start command/response communication either with 3.3V signaling modes or 1.8V signaling modes. An identification sequence after power up, called LVS Identification, is used to select either signaling mode. LVS cards can identify LVS hosts via the LVS Identification by checking the specified clock period on SDCLK pin and signal lines level at clock edge. If an LVS host is identified, the LVS card selects 1.8V signaling; otherwise, it selects 3.3V signaling.

I have no idea what this means, but it does not give me confidence that legacy UHS-I capable microcontrollers can use the LVS feature.  It makes it sound like there is some new wrinkle in the initialization process. 

[Rasz]

I have no idea what this means, but it does not give me confidence that legacy UHS-I capable microcontrollers can use the LVS feature.  It makes it sound like there is some new wrinkle in the initialization process. 

sounds like autodetect to me

[EEEnthusiast]

If you could do a small board with the IP4856CX25, the SD card connector and another high speed connector to the FPGA board, your problem could be solved. The small board wont cost much even with the microvias. You could use fine pitch board to board connectors and add extra mechanical strength using nuts, bolts and spacers.

[asmi]

If you could do a small board with the IP4856CX25, the SD card connector and another high speed connector to the FPGA board, your problem could be solved. The small board wont cost much even with the microvias. You could use fine pitch board to board connectors and add extra mechanical strength using nuts, bolts and spacers.

I did investigate this solution, and it turned out very expensive unless I invest a ton of money and make a very large run. But more broadly speaking, this whole thing sounds like a solution to a problem that shouldn't exist in the first place. I left this project alone for now, but I would skill very much like to know if any sane solution exists.

[mark03]

But more broadly speaking, this whole thing sounds like a solution to a problem that shouldn't exist in the first place. I left this project alone for now, but I would skill very much like to know if any sane solution exists.

So would I!  Very curious to hear if someone has tried the A2 cards in a 1.8V-only system.  Agree that the whole situation is sort of ridiculous.  It would make a good case study in the perils of backwards compatibility.

[asmi]

This is an old topic, but now we finally have a proper solution: https://www.nxp.com/part/NVT4858HK#/ This part is available in QFN-like package.

[mark03]

Thanks for sharing this!

I am still wondering though, Do we know if level translation is actually required in a 1.8V system, where you have the option of choosing the SD card yourself?  Interested in both "official" and "unofficial" answers.

[mroberto]

From the datasheet:

...
- Support SD/SIM card supply voltages with range of 1.65 V to 3.6 V
- Host microcontroller operating voltage range: 1.08 V to 1.95 V
...

Isn't 1.95 V a little bit too low on the microcontroller side?

[asmi]

Isn't 1.95 V a little bit too low on the microcontroller side?

No, that's perfect for 1.8 V logic level.

[antercreeper]

The worst things is those level shift chips are really hard to obtain and very expensive......
I choose ti TXB0104 and TPS62743, or an adjustable LDO is ok.(From datasheets, you can change TPS62743's voltage during running by changing vsel pins.)
of course you can make a power switch if your system has both 1.8V and 3.3V rails, for example mp5095)
These chips are really really common and very cheap.

[KreAture]

Just so you guys know. I found this info about the LVS identification sequence that allows all signaling to card to run at 1.8v without the LVS changeover after init.
( https://community.st.com/t5/stm32-mcus-products/sdmmc-peripheral-in-stm32l4a6-unable-to-run-with-the-usd-card/td-p/646645 )
After testing it I was able to verify a compatible cards response as attached!
However, after this activation the card does not respond to any reset command to put card in SPI mode.
I have verified that signaling at 3.3v and running normal SPI initialization works on same card so it appears this mode does not support SPI?
There is no mention of this in any documentation I have access to.

[KreAture]

It appears the LVS detection sequence activates LVS early as if voltage switch has been performed. As such it locks out SPI mode.
The only reference I found to this being the case is in the simplified spec 6.00 stating "After switching 1.8V singling, the card cannot be changed to SPI mode." and yes they write "singling". 

[mark03]

Any idea if LVS is supported by all/most modern cards?  Or is it more hit or miss?  It would be nice to dispense with the level translator altogether, especially on a project where you have some control over the memory card being used.  Most MCUs support some form of four-bit SD protocol, so the lack of SPI doesn't seem like a big deal to me.

[KreAture]

Any idea if LVS is supported by all/most modern cards?  Or is it more hit or miss?  It would be nice to dispense with the level translator altogether, especially on a project where you have some control over the memory card being used.  Most MCUs support some form of four-bit SD protocol, so the lack of SPI doesn't seem like a big deal to me.

Actually I did find that application level A2 requires LVS support.
I also found Kingston A1 card SDCA/128GB to support it as well as PNY Elite 256 GB. Latter card labelled Y2AGK34 on the back.
In my case I am locked to a MCU that only supports SPI, and it's QSPI has hardcoded commands only working with NOR flash. (Yes I know, why did they do that!!!)

[asmi]

In my case I am locked to a MCU that only supports SPI, and it's QSPI has hardcoded commands only working with NOR flash. (Yes I know, why did they do that!!!)

QSPI != SDIO, these are completely different protocols. MicroSD cards talk SDIO, but not QSPI, NOR flash is the opposite - it talks QSPI, but not SDIO.

[SiliconWizard]

Any idea if LVS is supported by all/most modern cards?  Or is it more hit or miss?  It would be nice to dispense with the level translator altogether, especially on a project where you have some control over the memory card being used.  Most MCUs support some form of four-bit SD protocol, so the lack of SPI doesn't seem like a big deal to me.

1.8V level is required for the higher speeds as per the SDIO spec, and indeed many high-capacity, recent SD cards do support it, unless they are complete dogs.

So if you want to communicate at the higher speeds (don't remember off the top of my head the threshold, will have to look back at the spec), you need to switch to 1.8V. Also, the card itself advertises if it supports switching to 1.8V or not. A SDIO host never *has* to do so. It always starts at 3.3V and if 1.8V is available, it is allowed to switch to that, but doesn't *have* to. Just that, as I said, if the host only supports 3.3V, it won't be able to use the higher speeds. But that's all there is to it.

[mark03]

Any idea if LVS is supported by all/most modern cards?  Or is it more hit or miss?  It would be nice to dispense with the level translator altogether, especially on a project where you have some control over the memory card being used.  Most MCUs support some form of four-bit SD protocol, so the lack of SPI doesn't seem like a big deal to me.

1.8V level is required for the higher speeds as per the SDIO spec, and indeed many high-capacity, recent SD cards do support it, unless they are complete dogs.

Well, sure, but we already knew that.  The question here is how many cards support LVS, which means that 3.3V is *never* required, even at start-up.

[asmi]

1.8V level is required for the higher speeds as per the SDIO spec, and indeed many high-capacity, recent SD cards do support it, unless they are complete dogs.

MicroSD (unlike full SD) cards are required to support 1.8 V mode.

So if you want to communicate at the higher speeds (don't remember off the top of my head the threshold, will have to look back at the spec), you need to switch to 1.8V. Also, the card itself advertises if it supports switching to 1.8V or not. A SDIO host never *has* to do so. It always starts at 3.3V and if 1.8V is available, it is allowed to switch to that, but doesn't *have* to. Just that, as I said, if the host only supports 3.3V, it won't be able to use the higher speeds. But that's all there is to it.

Well technically microSD card also doesn't HAVE to switch to 1.8 V - if SD2.0 (IIRC 50 MHz=25 MB/s over 4 lanes) is all you need, you are good to go with 3.3 V signaling.

This is unlike MMC, which does support 1.8 V only signaling without having to switch around.

[SiliconWizard]

Yep, well if you really want to support 1.8V switching (and not have to rely on microSD cards supposed to support 1.8V without having to switch from 3.3V), there is also the NXP NVT4858, available in a QFN package (if it hasn't been suggested already). Saw that you initially were not too keen on using a fine-pitch BGA for this. It's a 0.4mm pitch QFN, probably easier to route without indecent PCB costs. It's in stock @ Digikey: https://www.digikey.com/en/products/detail/nxp-usa-inc/NVT4858HKZ/15792204

[KreAture]

In my case I am locked to a MCU that only supports SPI, and it's QSPI has hardcoded commands only working with NOR flash. (Yes I know, why did they do that!!!)

QSPI != SDIO, these are completely different protocols. MicroSD cards talk SDIO, but not QSPI, NOR flash is the opposite - it talks QSPI, but not SDIO.

I think you misunderstood my statement.
I know very well they are not the same, and I assumed everyone else did too. I am stating my MCU does not support SDIO although they did supply a QSPI hardware unit.
My point was that they did not even let you encode custom command sets or specify commands for the hardware so it is completely locked to NOR flash. This is a shame as a lot of NAND flash have a NOR compatible mode that just need a few bytes changed in command set to be compatible. Thus I am looking for a way to use the SD cards, preferably in LV mode (not just LVS) and this is where the LVS detection comes in. Cards that support LVS detection is one step closer to LV mode as they allow init at 1.8v signal levels so you do not need level shifters. You would specify 2.7-2.8v voltage bracket to the card for supply (allowing it to run of lower voltage battery than 3.3v would) and you signal to the card at 1.8v activating the LVS detection. In my case I wanted to activate the SPI mode so I can leverage the DMA driven SPI hardware at least.

I made tests for this and can indeed activate LVS mode while signaling at 1.8v but it does not respond to SPI activation.
Thus I made code that allow for verifying that I can talk to it in 1-bit SD mode, and at 3.3v this code works and card responds to CMD8, CMD55 and ACMD41 so far. There is no response from CMD0.
Changing to 1.8v there is no response. If I run LVS detection first the card responds in about 2.3ms which is within the required 5ms, but later 1-bit SD-mode commands do not result in any responses.
This is very sad as it would open up the use of SD cards a lot.

[nimish]

Just use a PI4ULS3V4857 or NVT4858 and save yourself the trouble. Jlc will do 0.4mm bga assembly so you could make a breakout pretty easily https://www.diodes.com/part/view/PI4ULS3V4857

[glenenglish]

FWIW . I tried the 1.8V native way...., and it was too much hit and miss on different cards.... Micron industrial worked...

so I have on the most recent ZYNQ design, gone back to a 3.3V translator and I run it always at 3.3V.

Yeah, eMMC is nice, 3.3V aux , 1.8V IO. but the packages are huge.....
glen

[cearlobe]

Have used the NVT4858 without issues. Very straightforward.

[KreAture]

It's really sad they added such a good idea to the standards only for it to be so half-assed in implementation.
The market simply did not get the supply of Lv cards that I think they expected.
For devices where battery voltage starts at 3.1v and goes down from there, it kind of eliminates µSD as an option for powering.
LVS is nice for signaling directly from MCU but only if it can be done from the start. My tests show that this works, but only for SD protocol. SPI being disabled as soon as you trigger LVS detection seems like a very hostile act.
NVT4858 seems far superior to PI4ULS3V4857 in regards to the idle power draw btw and is only a bit more expensive. I will have to go this route in order to leverage the hardware for communication speed. It's a shame really, when the chips prove they can indeed signal nicely at 1.8v without any translator, but a complex protocol under NDA and license prevents it's use.

Btw: Receiving and sending data at high speed, synched to the SPI driven CMD channel for SD can be done by leveraging a UART peripheral module in synchronous mode using the SPI clock as clock source. Detect the start of transmission bit and halt the clock to set up reception, then let it rip. Allows for nice speed vs bit-bang and will let comms run native 1.8v in SD mode. Unfortunately for me the nRF5340 does not have synchronous serial capabilities...

[asmi]

It's really sad they added such a good idea to the standards only for it to be so half-assed in implementation.
The market simply did not get the supply of Lv cards that I think they expected.
For devices where battery voltage starts at 3.1v and goes down from there, it kind of eliminates µSD as an option for powering.

That's not entirely true. I seem to recall that standard specifies that cards shall work down to 2.8 or 2.9 V. There are many battery charger ICs which can maintain constant output voltage regardless of current battery voltage with very high efficiency, so that's also not a big deal. The biggest problem seems to be that all current NAND flash requires voltage higher than 1.8 V for programming, hence even eMMCs have two power rails - 3.3 V for flash and 1.8/3.3 V for IO interface.

LVS is nice for signaling directly from MCU but only if it can be done from the start. My tests show that this works, but only for SD protocol. SPI being disabled as soon as you trigger LVS detection seems like a very hostile act.
NVT4858 seems far superior to PI4ULS3V4857 in regards to the idle power draw btw and is only a bit more expensive. I will have to go this route in order to leverage the hardware for communication speed. It's a shame really, when the chips prove they can indeed signal nicely at 1.8v without any translator, but a complex protocol under NDA and license prevents it's use.

Btw: Receiving and sending data at high speed, synched to the SPI driven CMD channel for SD can be done by leveraging a UART peripheral module in synchronous mode using the SPI clock as clock source. Detect the start of transmission bit and halt the clock to set up reception, then let it rip. Allows for nice speed vs bit-bang and will let comms run native 1.8v in SD mode. Unfortunately for me the nRF5340 does not have synchronous serial capabilities...

I actually wouldn't mind having only SD protocol available as it's much better suited for block transfers. Also many MCUs have SD/MMC peripherals, so it's not even that hard to find a suitable one for just about any application. I just wish that they would've designed some kind of magic combination of pull-ups and pull-downs to switch card to 1.8 Vccio as opposed to current commands sequence.

[KreAture]

I actually wouldn't mind having only SD protocol available as it's much better suited for block transfers. Also many MCUs have SD/MMC peripherals, so it's not even that hard to find a suitable one for just about any application. I just wish that they would've designed some kind of magic combination of pull-ups and pull-downs to switch card to 1.8 Vccio as opposed to current commands sequence.

That's exactly what they have done. My code proved that it also works!
All that is needed is a single clock pulse of a long duration and card will acknowledge the switch before any commands are sent. All you need is to pull the pins low instead of high to start with, and give this 1.8v clock pulse. Card will respond with pulling DAT2 high (1.8v levels high). Once you start feeding it clock pulses the card will release the high drive on DAT2 after about 2 pulses and a slight delay.
As long as you want to communicate with card over SD protocol it is now ready for the normal init. Just remember that SPI can now not be enabled unless you power cycle card.

[asmi]

That's exactly what they have done. My code proved that it also works!
All that is needed is a single clock pulse of a long duration and card will acknowledge the switch before any commands are sent. All you need is to pull the pins low instead of high to start with, and give this 1.8v clock pulse. Card will respond with pulling DAT2 high (1.8v levels high). Once you start feeding it clock pulses the card will release the high drive on DAT2 after about 2 pulses and a slight delay.
As long as you want to communicate with card over SD protocol it is now ready for the normal init. Just remember that SPI can now not be enabled unless you power cycle card.

Is this compatible with every single card out on a market?

[KreAture]

That's exactly what they have done. My code proved that it also works!
All that is needed is a single clock pulse of a long duration and card will acknowledge the switch before any commands are sent. All you need is to pull the pins low instead of high to start with, and give this 1.8v clock pulse. Card will respond with pulling DAT2 high (1.8v levels high). Once you start feeding it clock pulses the card will release the high drive on DAT2 after about 2 pulses and a slight delay.
As long as you want to communicate with card over SD protocol it is now ready for the normal init. Just remember that SPI can now not be enabled unless you power cycle card.

Is this compatible with every single card out on a market?

No, only cards supporting full LVS (Lv? seems to be just confusing?) but from my understanding all A2 application class cards must support it. My Samsung EVO Plus A1 card also does so.

[asmi]

No, only cards supporting full LVS (Lv? seems to be just confusing?) but from my understanding all A2 application class cards must support it. My Samsung EVO Plus A1 card also does so.

All microSD cards are required to support commanding to switch to 1.8 V signaling. Are you saying that all microSD cards support your way to start them in 1.8 V signaling?

[KreAture]

No, only cards supporting full LVS (Lv? seems to be just confusing?) but from my understanding all A2 application class cards must support it. My Samsung EVO Plus A1 card also does so.

All microSD cards are required to support commanding to switch to 1.8 V signaling. Are you saying that all microSD cards support your way to start them in 1.8 V signaling?

No, they must specifically support this ability to transition to LVS mode before initialization. Some cards do, but I do not know the way to tell other than asking the card and seing if it transitions.
One very important thing to do when initializing card after "greeting it" with the LVS identification is to set the 1.8v range NOT the 3.3v in the SET_IF_COND (CMD8) parameters. This is VHS bit 9, instead of bit 8 for 3.3v. If you do not do this, the card will no longer match the interface conditions and will not respond. This is the second check that a card supports the direct 1.8v init. First being the acknowledge on DAT2.

[asmi]

No, they must specifically support this ability to transition to LVS mode before initialization. Some cards do, but I do not know the way to tell other than asking the card and seing if it transitions.

Well, that's kind of a problem. I can't tell to my customers to just keep buying cards until they happen to get one that works.

[KreAture]

No, they must specifically support this ability to transition to LVS mode before initialization. Some cards do, but I do not know the way to tell other than asking the card and seing if it transitions.

Well, that's kind of a problem. I can't tell to my customers to just keep buying cards until they happen to get one that works.

This is exactly why I am disappointed.
I read the specs, I check and then I confirm what works. Result is a view that somehow they added a feature without adding proper guidelines for when it should be supported, or made it to only be required for a very narrow high class of cards. Regardless you are absolutely right that as it stands, with current insight, it is a hit & miss situation and not at all acceptable.

[glenenglish]

Next ZYnq design, I might use an eMMC in 4 bit mode

It is (in Zynq) compatible with the SDIO controller meant for SD cards. IE eMMC/ microSD card- doesnt care,

although :
eMMC solution :
- the eMMC though is huge 14 x 18mm.  but wont need 1.8V logic translator (runs on 1.8V)   252mm2
(- needs USB or BT interface to load SW and talk to the outside work. at least 4x4 QFN for FTDI USB)
- and USB Type C socket (9.6 x 7.6) 73mm2  +FTDI 4x4 chip =16mm2  total 89mm2,  Or Bluetooth solution 8x 12 = 96mm2
- FSBL bootflash 6x 5 = 30mm2

microSD card  solution :
board area : 14.5 x 15.6  (226mm2)
3.3V <> 1.8V translator  (4 x 4 QFN) (16mm2)
no FSBL bootflash

microSD still wins on simplicity.
can quite follow it but did we find a translator with 0.5mm pitch or above ? none of this 0.35mm pitch QFN, please.
-TXS02612 (0.5mm pitch) looks workable.

[asmi]

1. You an preload stuff on eMMC prior to soldering it, there are affordable devices which can do that.
2. You can have both SD and eMMC! You will need to route eMMC through EMIO to PL pins.
3. NVT4858HK is in QFN16 package with 0.4 mm pitch, which is very doable without any special processing.

[KreAture]

Next ZYnq design, I might use an eMMC in 4 bit mode

It is (in Zynq) compatible with the SDIO controller meant for SD cards. IE eMMC/ microSD card- doesnt care,

although :
eMMC solution :
- the eMMC though is huge 14 x 18mm.  but wont need 1.8V logic translator (runs on 1.8V)   252mm2
(- needs USB or BT interface to load SW and talk to the outside work. at least 4x4 QFN for FTDI USB)
- and USB Type C socket (9.6 x 7.6) 73mm2  +FTDI 4x4 chip =16mm2  total 89mm2,  Or Bluetooth solution 8x 12 = 96mm2
- FSBL bootflash 6x 5 = 30mm2

microSD card  solution :
board area : 14.5 x 15.6  (226mm2)
3.3V <> 1.8V translator  (4 x 4 QFN) (16mm2)
no FSBL bootflash

microSD still wins on simplicity.
can quite follow it but did we find a translator with 0.5mm pitch or above ? none of this 0.35mm pitch QFN, please.
-TXS02612 looks workable.

I am receiving NVT4858HKZ in XQFN today as I too want to avoid the 0.35 BGA's. It's 1.8x2.6mm aka 4.48mm2 but require a bit more for footprint.
(2.3x3.15 = 7.245mm2 occupied area.) I am mostly looking to verify actual power draws signaling at 1.8v->3.3v vs using native 1.8v on card via LVS detection init.