SD card/SDIO 3.0 level translation solution

[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.