STM32F4 - SDIO_CK not stable at 48Mhz

[bard]

Posted on October 04, 2012 at 14:23

I want to read/write data from an sd card in high speed 4-bit mode. However the SDIO_CK seems to be wrong when I set the bypass bit to run it at 48MHz ( from PLL48CLK ).

Every seventh/eigth cycle is way to long, with a period of 110ns as apposed to 20ns (which is 50Mhz). I notice this difference at 400KHz and 25Mhz as well, but it so small it is still within the clocking of data signals. I have checked with a logic analyzer and the CMD signal is clocked out at 50MHz, but I assume the sd card cannot clock the data in once the CLK signal is ''hanging''(and the CMD data is still being clocked out) Does anyone have some ideas or comments on this? I have tested this on two different STM32F4 mcu's(totally different hardware as well) and the glitch in SDIO_CK is quite the same on both chips.

[Tesla DeLorean]

Posted on October 04, 2012 at 15:18

Does anyone have some ideas or comments on this?

Synchronous infers data validity wrt to a clock edge, not a frequency. 8 x 4-bits is 32, I'd look at the DMA and FIFO settings.SDIO_CK is almost certainly gated based on availability of data, the clock will stall as required. PLL48CLK is not directly available for output, but the PLL clock it is divided from can be viewed at MCO pins.

[bard]

Posted on October 04, 2012 at 16:12

Three questions:

1. Isn't PLL48CLK available on output when I set the BYPASS bit? Isn't that the point of this setting? I certainly get the PLL48CLK when setting the BYPASS bit. 2. Why do SDIO_CK vary so much? The time difference noted below is timed when just enabling the SDIO_CK on the CLK line, no data is sent. 3. I understand that data transfers relate to the clock edge, but why do I see bits being sent over the CMD line while the CLK line remains high during this time? If i read out the bits on CMD(in the logic analyzer) the bits are correct, but if I read out the bits on CMD at the CLK edge some bits are not read.

[Tesla DeLorean]

Posted on October 04, 2012 at 17:53

The SDIO_CMD pin is bidirectional, it can be driven by the Card.

A disparity in the clocks between subsystems will likely result in an apparent stall or cycle slip, at a regular beat period. Not saying this is what you're seeing, but it could be, try running a 144 MHz instead of 168 MHz. The FIFO contains a 32-bit wide, 32-word deep data buffer, and transmit and receive logic. Because the data FIFO operates in the APB2 clock domain (PCLK2), all signals from the subunits in the SDIO clock domain (SDIOCLK) are resynchronized. Stopping the SDIO_CK is a method of pacing the transfers. 26.6.2 SDIO read wait operation by stopping SDIO_CK If the SDIO card does not support the previous read wait method, the SDIO can perform a read wait by stopping SDIO_CK (SDIO_DCTRL is set just like in the method presented in Section 26.6.1, but SDIO_DCTRL[10] =1): DSPM stops the clock two SDIO_CK cycles after the end bit of the current received block and starts the clock again after the read wait start bit is set. As SDIO_CK is stopped, any command can be issued to the card. During a read/wait interval, the SDIO can detect SDIO interrupts on SDIO_D1. BYPASS eliminates a divider chain, it does not preclude the clock being gated. I'd verify that the PLL clock source is stable via the MCO pins, and confirm that the SDIO_CK was just being suppressed for integral clock periods. If that's the case you're observing the internal mechanics of the SDIO implementation and the state machine. You'd have to consult with ST engineers about the internals.

[bard]

Posted on October 04, 2012 at 19:19