Hardware Developers Community - NI sbRIO & SOM

cancel
Showing results for 
Search instead for 
Did you mean: 

SD Card Detection

Greetings,

I've designed a SOM carrier module that includes an SD card interface. It was designed identical to the reference designs but we are unable to get it functioning. When a card is inserted, SD_CD# is low but we never see  SD_PWR_EN go high. We've gotten most of the rest of our design running so the SOM is functional. If we run our same code on the reference PCB we are able to access the SD card. One difference is the our carrier PCB does not have anything connected to the USB interface on the SOM. Could that cause issues? Any other ideas? ANy way to see if the SOM is properly detecting SD_CD#?

Thanks.

-Brent

0 Kudos
Message 1 of 6
(7,621 Views)

The SD interface does not rely on the FPGA IO, so the FPGA code running on the SOM should not influence the SDCard functionality.

If the connections are correct, then the SDCard socket should 'just work'.  The USB interface is also functionally isolated from the SD interface, so I don't foresee any complications there.

Are you probing the SD_CD# signal near the SD connector or near the SOM searay connector? Can you verify the resistor values and connections to the pull-up and series termination resistors connected to SD_CD#?

As a debug attempt, can we try to override the Card Detect switch functionality?  Plug an SD card into the socket before applying power, and hard tie the Card Detect to ground.  Then power on the carrier/SOM, which should cause the interface to attempt to initialize on bootup. 

There may be a way in Linux to query the SD driver for the state of the SD_CD# signal, but I'm not familiar enough with Linux and this driver to make a recommendation there.  I know some of the SOM developers have also seen this post, and we will continue to think about this debug.  Any additional comments/details you can give us on the overall design and debug steps you have resolved would be helpful. 

-spex

Spex
National Instruments

To the pessimist, the glass is half empty; to the optimist, the glass is half full; to the engineer, the glass is twice as big as it needs to be has a 2x safety factor...
0 Kudos
Message 2 of 6
(6,506 Views)

I spent a bit of time today looking more closely at this issue. When SD_CD# goes low, about 200mS later SD_PWR_EN pulses high 4 times. Each pulse is about 70mS with about 2mS in between pulses. It is as if the SD controller on the SOM is looking for something and not seeing it so it is power cycling it to retry. After the 4 pulses SD_PWR_EN stays low.

Resistors on the SD_CD# and SD_PWR_EN are identical to the reference design with 1K pullups and 68 ohm series terminators. I double checked them also with a meter.

-Brent

0 Kudos
Message 3 of 6
(6,506 Views)

Hi Brent,

We were able to reproduce the behavior you described where SD_PWR_EN pulses four times by shorting the SD card power supply. It appears that the SDHCI driver and controller is waiting for a the card to respond.

If you followed the customer reference board schematic identically, the most likely cause I would suggest looking into is verifying the schematic symbol and cell of the SD Card connector you are using is correct and not miswired. It may be that the card detect signal is connected correctly, but that either power is routed to the wrong pin on the connector or one of the SDIO data signals are routed incorrectly.

The reference board is using a Honda AXA2R73061P-M SD Card connector.

-Tanner

Tannerite
National Instruments
0 Kudos
Message 4 of 6
(6,506 Views)

Thanks. The layout engineer mirrored the pins on the Hirose connector we are using. The data sheet has the footprint drawing shown from a top view but the drawing that shows which pins are 1-9 is from a bottom view. I'll fix it on the next spin. Thanks for you efforts.

0 Kudos
Message 5 of 6
(6,506 Views)

Hi Brent,

Glad to hear you found the source of the issue, and the resolution is straightforward, albeit time-consuming to wait for a new board rev.  I can also relate to your issue though.  I wish I could claim that NI has never had an SDCard footprint symbol error on an early board rev.

Hopefully you already have most of the other parts of the carrier board validated and the changes for the next rev are minimal.

Regards,

spex

Spex
National Instruments

To the pessimist, the glass is half empty; to the optimist, the glass is half full; to the engineer, the glass is twice as big as it needs to be has a 2x safety factor...
0 Kudos
Message 6 of 6
(6,506 Views)