I have 5 Xavier AGX development kits (DKs). Two of them, after being in use for experiments for one year, are not able to see the SDCARD. I tried “full flashing” many (unmodified) Jetpacks & L4Ts 32.{6,6.1,7.1}. I also tried messing with DTBs, but it should not be needed on the DKs… sdhci3 shall already be operative after plain reflash if I understand correctly.
When I insert the SDCARD nothing happens (dmesg remains silent).
On the 2 DKs that are not able to see the SDCARD I see the following with SDCARD inserted.
sudo cat /sys/kernel/debug/mmc1/ios
clock: 0 Hz
vdd: 0 (invalid)
bus mode: 2 (push-pull)
chip select: 0 (don't care)
power mode: 0 (off)
bus width: 0 (1 bits)
timing spec: 0 (legacy)
signal voltage: 0 (3.30 V)
driver type: 0 (driver type B)
The same SDCARD on a working DK shows:
sudo cat /sys/kernel/debug/mmc1/ios
clock: 208000000 Hz
vdd: 21 (3.3 ~ 3.4 V)
bus mode: 2 (push-pull)
chip select: 0 (don't care)
power mode: 2 (on)
bus width: 2 (4 bits)
timing spec: 6 (sd uhs SDR104)
signal voltage: 1 (1.80 V)
driver type: 0 (driver type B)
What tests can I perform to understand what is wrong on the sdhci3 of those two DKs?
Where can I find other information? If the boards are faulty I’d like to understand which component is defective so that in our possible final design we can address the problem.
Note: for one year or more the board has been operative with the SDCARD slot empty. Because the board is difficult to reach I don’t know if the contacts on the SDCARD are “clean”. I’ll try to spray some air into the slot just in case as a last resort next time I reach one.
You can compare the dmesg between the working one and the NG one.
Also, remove the module out from that carrier board, move to another AGX board and see if the issue is still. This can clarify whether the carrier board is broken.
The problem is not solved, but a workaround has been found, which allows me to move on.
The problem was related to both the Xavier AGX and the SD card.
Three of my Xavier AGX boards (all freshly flashed from the same binaries, the same JetPack directory indeed) can read any SD card. The other two (of my five) AGX boards can read only some “brands” (Sandisk and Toshiba seem to work) of SD cards.
So I believe the Xavier AGX sdcard reader are maybe “picky” about reading cards operating at the edge of the specification limits. Some AGX samples are maybe more picky than others for some fluctuations related to the Xavier AGX production process tolerances.
I leave this comment to leave track of this potential quality issue of the AGX development board.
P.S.: I can’t provide dmesg output because the boards are busy for our tests at the moment. Anyways, when the “problematic” sdcard is inserted, noting gets appended to dmesg. So there would be little to see in dmesg.
This is a little weird that “nothing is shown in dmesg”. Because the card detection is just a GPIO input work. GPIO has no function to be picky for what brand to be used here. It is just pull up and down function… Unless some kind of sdcards are not able to trigger the GPIO input on AGX board…
That is why I lost some considerable amount of time on the topic. I could not believe that the same SD card can work on one board and not on another one. I was suspecting the two not working to be defective/misconfigured… but, to my surprise, just plugging in a different SD card “solved” the issue. :-O
I have 15 of those “strange” SD cards and two “strange” Xavier AGX. If there is something I can do to better understanding this weirdness, juts let me know and (ASAP) I’ll try to come back with more information.