SDIO PROBLEM

[xtian]

Posted on April 09, 2013 at 17:29

 

 

The original post was too long to process during our migration. Please click on the attachment to read the original post.

[Tesla DeLorean]

Posted on April 09, 2013 at 17:36

Do you have the SDIO_IRQHandler() ?

[xtian]

Posted on April 09, 2013 at 17:57 Thanks clive, I tried to add it from the stm32f2xx_it.c

void SDIO_IRQHandler(void)
{
/* Process All SDIO Interrupt Sources */
SD_ProcessIRQSrc();
}

then include it on its .h I don't know what to do next

[xtian]

Posted on April 10, 2013 at 09:09

Hi Clive1,

I have enabled it at NVIC.. making sure that SDIO_IRQHandler is Enabled.. didn't resolve problem... does it something to do with my system _stm32f2xx?

/* PLLVCO = (HSE_VALUE / PLL_M) * PLL_N */ 
#define PLL_M (HSE_VALUE / 1000000) /* Possible value 0 and 63 */
#define PLL_N 240 /* Possible value 192 and 432 */
/* SYSCLK = PLLVCO / PLL_P !!!! DO NOT EXCEED 120MHz */
#define PLL_P 2 /* Possible value 2, 4, 6, or 8 */
/* OTGFS, SDIO and RNG Clock = PLLVCO / PLLQ */
#define PLL_Q 5 /* Possible value between 4 and 15 */
/* I2SCLK = PLLVCO / PLLR */ 
#define PLL_R 2 /* Possible value between 2 and 7 */

[Tesla DeLorean]

Posted on April 10, 2013 at 12:33

Doesn't appear unreasonable.

If you have a code example that works, you'll need to contrast that with the one that doesn't. If you're porting code to a different project pay attention to the defines (command line ones), and pin assignments related to the board being used.

[xtian]

Posted on April 11, 2013 at 07:47

Hi Clive1,

Thank you very much! do you have a skype? im having a problem using this forum at home.. my connection is quite slow...  I will try to make an atom to atom comparision for this and will let you know if I found something... Thank you very much for the help... at least now I have a quite better understanding on what is happening on the sample code.

I would like to ask again if the system_stm32f2xx.c configurations has nothing to do with my USART and SDIO?

here's the scenario:

ON THE EXAMPLES OF STD PERIPH for IAR under STM32F2:

SD is working so I tried using that project file as an integration point where I integrate my usart communications to the LCD at that project and the result is: my SDIO is working my LCD(usart) is not displaying anymore - > though I have not able to see the data in actual on my PC since my friend borrowed my trainer board (which include my Level converter circuit)

and the other one.. this scenario....(usart working SDIO not working)

Actions:

atom to atom comparison

to do everything from scratch...->create the project from scratch...

[Tesla DeLorean]

Posted on April 11, 2013 at 15:43

I do, but I'm not looking for that level of engagement.

In system_stm32f4xx.c I guess the first place to look would be PLL_Q, as that provides the SDIO clock source. There are rules relating to AHB/APB and SDIOCLK, not sure they are in play here, but check the docs.

I think you should also review if there are any pin conflicts amongst the peripherals you're attempting to use together.

[xtian]

Posted on April 15, 2013 at 13:36

Hi Clive1,

I have resolved it..(this is again a new learning from me) It seems that the olimex libraries that can with the board has a timing configured based on its 12 Mhz Oscillator. and discovery boards uses 25Mhz Oscillators. I got messed up on the timings that is why I am having hardware fault.. it is now working fine:) thanks so much!

[Tesla DeLorean]

Posted on April 15, 2013 at 14:14

The DISCOVERY boards typically use 8 MHz, the EVAL boards typically use 25 MHz

HSE_VALUE must always match the reality on the board.

[xtian]

Posted on April 16, 2013 at 07:07

Noted!... Thanks clive1