1 of 1 people found this helpful
That level translator looks quite good. I'll see if I can find anyone else using it for SD - apparently the SD card internal pullups can cause issues for some of the automatic bidirectional translators.
I've also just found the MAX13032, which is designed for this task (so it'll hopefully work well). Unfortunately it's not particularly cheap. About $5 if you buy individually, which is more than the STM32F3 is going to cost. Not a huge problem, but still annoying.
Interfacing to the STM32 will need level translators, but it'll be through either SPI or UART (most likely SPI at this stage). Since neither of those use bidirectional lines, level conversion is trivial.
Thanks for the pointer to the MAX13032. That also looks like a goo one.
I feel your pain with the seemly out-of-whack costs of some seemly simple items. BTW, have you seen the STM32F072? It has a secondary IO bus that can run at a different voltage level than the rest of the chip. Unfortunately, it includes the USB and SWD pins, so it's less useful than it can be, but I'm thinking about using that as an interface expansion MCU. I'm not so sure it would be a good idea for SD card, though, since I assume one should be able to boot from the SD card if it's attached to the SOC directly, but not if it's interfaced through an MCU.
1 of 1 people found this helpful
I hadn't seen the STM32F072; it does look quite attractive. Thanks for the info.
As you say, the ideal thing would just be to have the Edison connect directly to the microSD card. Unfortunately there doesn't seem to be any really good way of doing that, especially if you want to be able to drop back down to 1.8V signalling (for the high-speed modes) after initialisation.
If there was a way to limit the Edison's SD peripheral to just using SPI mode then I'd probably do that. Slow, but level conversion costs virtually nothing for SPI (three low-to-high converters and a resistor voltage divider) and I'm not planning to boot from microSD very often. Unfortunately, without a full datasheet for the chip it's pretty much impossible to check whether that can be done.
Perhaps one of Intel's representatives could explain the "correct" approach? Surely they've built a couple of boards with SD sockets for testing.
Edit: with a lot of further research, it looks like the TI TXS0108 will do the job. My understanding is that the clock line has to be fed back through the chip to connect to the CLK_FB pin on the Edison. The TXS0108 is both cheap and (relatively) easy to solder.
Thanks for the update and the pointer to the TXS0108. Do you think that is better than the MAX13035E or just cheaper? It seems like the MAX13035E is specifically designed for connecting to an SD card.
I'm not sure I understand what you're saying about the clock line. Are you saying that you e.g. connect SD_0_CLK to A7 and SD_0_CLK_FB to A8 on the TXS0108, and then connect B7 and B8 both to the clock line on the SD card?
BTW, on the subject of connecting an STM32, I'm currently experimenting with programming an STM32 directly from the Edison using a pair of GPIO lines connected directly to the STM32 SWD lines. I've already hacked a version of Black Magic Probe firmware to bitbang GPIO on a Beaglebone Black and have been able to connect to an STM32 via SWD. It should also be able to flash the STM32 and debug, but I haven't tested it yet. I'll post an update in another thread when I've tested it more.
Just cheaper, and a bit easier to handle on the BoM since it can be used for other interfaces too (ie you can have two TXS0108 chips to do all your level conversion, instead of one MAX13035E and one TXS0108). It's also easier to get (no stock on the MAX13035E at Digikey) and easier to solder.
With the clock line, your description is correct. The idea is to compensate for delays caused by the level shifter, since those would mean that data received by the master is not in sync with the clock signal that was originally sent out. Since the feedback signal has gone through the level shifter in the same direction as the data, it will be in sync.
Regarding the SWD on the Edison: nice work! I'm planning to just hook up a UART and a couple of GPIO pins so I can use the embedded bootloader to load code. Not as flexible (can't debug with that method) but it should be adequate.
PI4ULS3V08MZLE Pericom has very limited toggle rates, as from the data sheet Fmax in 1.8/3.3V mode is less than 24mhz, lower than that 25Mhz clock for Default speed, half that for High Speed, and not even close to the 100MHz required for UHS-1 in 1.8V mode.
There must be a better solution.
I'm not sure who marked my first answer as the correct answer, but there was much more detailed analysis after that. I think I'm settling on the TXB0108, which appears to have a 60MHz bandwidth at 1.8-3.3V. I don't see how you can get the UHS modes without some much more complex arrangement that switches from 3.3V to 1.8V.
I guess the bigger question for the Intel guys, is does Intel even support UHS-1 or UHS-2? Do they have a recommended solution for UHS-1/2 if it does.
faceplant - that link does not seem to work.
As far as I can tell, the TXB0108 is not well suited to SD card level translation. SD cards have an internal 10K to 100K pullup on the DAT3 pin, and external pullups (in the same range) are recommended on the other data pins. The TXB0108 can handle 50K or higher pullups; lower resistances will overpower its output drivers and cause problems.
The TXS0108E (as mentioned above) is designed to handle this, and can manage 60Mbps throughput when doing 1.8V to 3.3V.
As you've said, handling the high-speed modes doesn't look easy. If that's all done in hardware then it's probably not possible (because there's no way to tell when the hardware has switched modes, and without that you can't change the voltage). I'm just going to live with the lower-speed modes for now; they'll probably still be faster than most SD cards can write, and 99% of the time I'll be using the internal flash anyway.
I had seen the limitation on pull up resistor value, and had intended to use 100k pull ups. Unfortunately, I missed the fact that DAT3/CD can have a smaller pull up on the SD card side. I like the smaller size of the TXB0108, but can live with the TXS0108E.
I just noticed that the TXS0108E has internal pull up resistors. I assume that should remove the requirement for adding additional pull up resistors, right? That would more than make up for the larger size.
Yes, the internal pullups should be fine. Just make sure that you tie the OE pin to VCC, so that the pullups are active as soon as the board gets power. If OE is low then you don't get any pullups.
I think I may have found another option: the NTS0104. It's only 4 channels, but it looks very similar to the TXS0108E, and the smallest package is ~1/4 the size of the smallest TXS0108E. It might not save too much space, since you're splitting one IC into two, but it looks like another reasonable option. The maximum speed is 50Mbps, which is cutting it close, but it is within spec.
I'm still trying to figure out how to implement the SD 3.0 speeds that the Edison Hardware Manual says it can support.
That pretty much leads me to using an NXT IP4853 which not only handles the speeds, but does the clock feedback right and includes full ESD protection as well.
The only tough nut using that device, is it's very tiny 2x2mm with fine pitch bga/csp package requiring via in pad.
Still haven't gotten an Intel response about how to implement UHS-1