On the devkit- I see 375khz clock (yellow), and Pin2[CMD] (red) start at 3.3V, then drop to 1.8V. The power supply (Pin4) stays constant at 3.3V.
Here are the images of the devkit’s signals (testing on the carrier board now):
3.3V
Is this one of the newer higher speed cards using four data lanes? Do you have an older card using a slower standard? Only the new ones drop to 1.8V and then only after commands detect the card uses 1.8V. It is surprising if it drops to 1.8V and didn’t detect the card.
I can’t read the images, a but low resolution, but does it seem plausible that the command channel is synchronously transferring 48-bit commands? Also, I’m not sure if the command channel itself should drop to 1.8V. Can you see if it does this same voltage drop when SD works correctly on a dev board? If on a dev it remains at 3.3V this may be it, but I don’t know the standard well enough to say.
Also, it looks like command is supposed to go through a 10k resistor. Can you verify the resistor on your carrier is 10k?
Can you also see the voltage on the command channel drop from 3.3V to 1.8V using the same SD card on the devel carrier? Or does the dev board stay at 3.3V for command channel I/O?
This card is the type-1 SDHC cards- type3 do not work. I’m guessing that this is one of the newer ones, and the only type-1 that I have. The first two images in my post above are from the devboard. This card does indeed start out at 3.3V, then detect that it works at 1.8V, then drops to 1.8V.
On the carrier board, it cycles through three clock speeds then gives up, never actually dropping to 1.8V.
I believe that CMD is supposed to go through a 10-ohm resistor- which is the case for the dev board and our carrier.
On the dev board, when the clock voltage drops to 1.8V, all other signals drop to 1.8V as well, including the CMD line.
On the custom carrier, it never actually establishes communication (my bet), gets more conservative on the clocks, and stays at 3.3V rail for all signals.
The command and data lanes are all impedance controlled. Are you able to get an idea of signal quality close to the Jetson module versus at the SD card? Do rising and falling edges seem to round more on the custom board? On levels, is there any tendency to slope downwards? Mostly close to the Jetson itself would be important since it is the Jetson which decides if signal is ok.
Do you know if there was a model done for impedance? Schematics show 50 ohm netclass. I’m just curious if the traces for your board were sufficiently different in length/shape that impedance would be off.
EDIT: It is perhaps silly of me to ask, but do you know if any copper plating thickness was taken into account when predicting impedance?
ANOTHER EDIT: I see references to controlled impedances usually being kept within 10%. If that resistor really is 12 ohm (and many multimeters won’t measure too accurately at 12 ohm), then this might be too much resistance.
One thing I just thought about…if you used the same exact slew rate and drive strength for impedance controlled SD card lines, and if your traces did not match the same length and other impedance details, then it might be a case of an exact match of device tree only working on the board with the correct impedance for those details. I’m not sure what you’d need to adjust or how to measure if this is the case.
The switch that turns the power on/off caves just enough to either reduce the response below the threshold signal or browns out the sdcard completely. Its almost invisible because it happens very quickly, only on boot and only just a few milliseconds.
I feel like there is so much great info here, and I hope it helps someone someday.
Easy fix.
Thank you so much! linuxdev for the win, you deserve a medal!
In the case for BoulderAI he had insufficient delivery issue (causing signal failure), which is normally a power bus design issue. If everything else is correct, then you can read the TRM with regard to slew rate and impedance controlled interfaces, but the correct values depend on the exact physical design (almost every board design will differ).
Tanks, I understand what you mean，but now I can’t easily change the hardware. After testing, I found that the SD card power enabled pin was forced to pull down, and the SD card could be identified. I don’t know how to modify this pin to keep it in a drop-down state(SDCARD_PWR_EN H16).
I do not know how to use software to ignore the physically wired pin. This may be possible, but someone else will need to answer (perhaps some PINMUX and device tree combination could be used). You might want to add a note as to whether the design will always have an actual SD card present.
