SAMD51 Trouble with SDHC using internal clocks

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

I have a custom board with an ATSAMD51G19A processor that uses SDHC among other things. Code for this board was designed and tested with a SAM E54 Xplained Pro, though the custom board lacks any external clocks, and different pins are used for the interfaces (including a switch from SDHC1 to SDHC0).

I made a new Atmel START configuration for the custom board, then adjusted the current code to use the new files from START. The CPU runs off of DFLL48M (which uses OSCULP32K as a reference), and peripherials either use that 48MHz clock or a division of it, like 12MHz. I've been trying different divisions to see if that affects the issue. The E54 configuration used XOSC32K instead of OSCULP32K.

The code gets stuck when the START-generated code tries to send commands to the SD card. In _mci_send_cmd_execute() (file hpl/sdhc/hpl_sdhc.c) the EISTR status register is polled after the command is written, which will ultimately read 0x03, indicating a "CMD line conflict." The internet hasn't provided much help in understanding how that conflict could be fixed. I feel like this issue is related to the clock setup, or something missing from the clock setup, because other than going from SDHC1 to SDHC0 that's the only thing that I believe has changed.

Has anyone had a similar issue, or could point me towards things to check/consider?

Thanks in advance.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

An update,

 

I got the SD clock signal on a logic analyzer, and measured a frequency of 400kHz (which I believe is right?). I couldn't get the analyzer to capture the command signal; I may try that again later.

 

The "CMD line conflict" is described as when the processor "drives the CMD line to 1 level, but detects 0 level on the CMD line at the SDCLK edge." The CMD line has a 10k external pullup, which leads me to believe something (the processor or SD card) is bringing the CMD line to 0.

Maybe the clock is too fast or too slow?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

 

did you have any luck with this? I'm having a similar problem. I'm on a custom board with Atmel Start. It successfully pulls the card info (capacity etc.), but then after the first call to mci_sync_adtc_start, the driver hangs waiting for the CMDINHD bit in PSR to go low, which it never does. I've tried all sorts of SD clocks from 12MHz to 100MHz, derived clocks from the CPU clock or not, checked all the traces, disabled 4-bit and high-speed mode, and tried a different SD card, none of which helped.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Never mind, after lots of software debugging I finally went back to the board and found that the solder joint directly at the SD_DAT0 pin of the SAMD51 was broken.

 

In the interest of anyone else having a similar issue: This error does not look like a hardware issue at first, because the driver successfully pulls some card info during initialization before hanging. This is due to the fact that command are sent over the CMD line, and the basic card info (supported voltages etc.) is also transmitted as a response on the CMD line, without involving the DATx lines at all. The first command that uses the DAT0 line is the CMD51 command that is sent to request the SD card configuration register (SCR). The command is sent over the CMD line and the reply is expected on the DAT0 line, which is when the driver hangs (which is not particularly good design IMHO, it should at least return a timeout or error instead).