cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F401RB SDIO

matas
Associate II
Posted on August 05, 2015 at 20:37

Hi all, there is something wrong with my project's microSD card part. I have done it on the  STM32F407 discovery board and it worked perfectly the data was succesfuly written to the microSD card. But for the end product I made board (whom all traces are correct, checked it many times) with STM32F401RBT6 and now the microSD card always not responds, I get error:''SD_CMD_RSP_TIMEOUT'' and later turn into FR_INVALID_OBJECT. I have changed the from startup_STM32F4xx.s to startup_STM32F40xx.s. And I am using STM324xg_eval.c and stm324xg_eval_sdio_sd.c as drivers. Also changed the clockfrom 168MHz to 84Mhz. The divider valus are:

*pll_n 336

*pll_m 8 (onboard external 8Mhz quartz)

*pll_q 7

*pll_p 4

APB1 Prescaler 2

APB2 Prescaler 1

 If you have any suggestions, ideas or questions you are very welcome to post. 

#stm32f401
Foo Bar
13 REPLIES 13
matas
Associate II
Posted on August 11, 2015 at 19:40

I've dug even depper and found what is not happening 🙂 Since I have a working prototype with STM32F4 Disco, I just compared what is different from my board with STM32F401 and found out that after the function SDIO_ClockCmd(ENABLE) the flag CLKEN doesn't go to 1 on my board. And thus the clock doesn't start and causes further errors. I still don't know why it is not happening, but at least I know the problem now 🙂

Foo Bar
matas
Associate II
Posted on August 12, 2015 at 11:18

I've just traced my mistake to the system clock, which by my surprise was running not on HSE, but HSI and PLLON was not set to 1, thus PLL wasn't even on 🙂 Don't know why is it not taking the HSE value? 🙂 Because the code first checks the HSE and only then takes HSI if HSE is not possible 🙂

Foo Bar
matas
Associate II
Posted on August 12, 2015 at 17:16

Well. I got stuck :D when I was searching why the STM is not taking the HSE value, I though maybe the caps were wrong, so I switch the 22pF -> 10pF, before that I tried to switch up the startup files. And now I can flash the program into the STM, but when the debbuger starts it puts the cursor into a random place inside memory for exmpl (0xffff8000) and will not move further, if by accident it ends up on a memory where the program is loaded, then it moves a few steps and jumps again 🙂 Any ideas why is it happening? 🙂 I tried to move the caps back, but that did not help 🙂

Foo Bar
matas
Associate II
Posted on August 13, 2015 at 08:12

I am not sure why, but it seems that the system_stm32f401xx.c was the problem, I switch it with the original from STM32F4 Disco and it started to work again. After this, the clock problem fixed it self and the SDIO started to work, although, I still can't set it to be 84MHz, the main thing got fixed 🙂

Foo Bar