ST32f4discovery+sdcard+fatfs problem

[arnold]

Posted on June 30, 2012 at 23:43

Hello, 

i have a small problem i think.With the help of this forum and google i created a project with CoIDE.What it should do is reading the directory of an SDCARD.The SDCARD part is working. but the fatfs is not working and i don't know what i'm doing wrong. I believe everything is oke. so i hope someone could help me. I attached the whole project.  #sdcard-stm32f4-sdio-fatfs

[Tesla DeLorean]

Posted on July 08, 2012 at 15:22

I tried to address the things which appeared wrong. I'm not it a position to test it, or determine why it is running from RAM

I'm using mostly Keil, the MSC example code I posted used Yagarto (GNU/GCC 4.7.1) from the command line.

[arnold]

Posted on July 08, 2012 at 15:28just fo me, to check i don't miss any step. i check with your bin file that sdcard is working since i can see it as mass storage.in my programm.i dosdinitconfigure interruptafter this it should be possible to read a block from the sdcard.could you maybe post a very simple program, that reads the root directoy of the sdcard.so i could analyze it to see if i missed somthing. if you use yagarto i probably could use it in coocox, becaus coocox use yagarto to compile the program's i would very appreace this.

[Tesla DeLorean]

Posted on July 09, 2012 at 20:36

You could try this.

Ok, updated with a working build. Had to fix the linker script to deal with ''.bss.*'' sections. Looks for MESSAGE.TXT, reads and counts bytes, save length in LENGTH.TXT Performs a crude directory and saves in DIR.TXT. Tested on an STM32F4-Discovery with a 2GB Micro SD Card. ________________ Attachments : fsfatdemo4disc_rev2.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HtWc&d=%2Fa%2F0X0000000aRG%2FZEKQhqJzQF0DP20aHxvevaIj8KEO7GcDK2bZKsLIzv0&asPdf=false

[arnold]

Posted on July 10, 2012 at 07:37

I just flashed your output file.

But it didn't write a text to the sd card. I will look tonight when i'm back at home if i could compile your project and try to find out where it goes wrong. Did you test this little project ?

[Tesla DeLorean]

Posted on July 10, 2012 at 19:18

I've tested something materially identical in Keil. This appears to be hard faulting. Perhaps it doesn't like the stack in CCM.

And no it does not write to the card. My primary platform is a custom F2 board, I have a MicroSD card tied to the STM32F4-Discovery now, and that is working.

[arnold]

Posted on July 10, 2012 at 19:36

You flashed your discovery with the bin file in your last attachment, and that one worked ? 

when i flashed it, it didn't work for me. the card detect is connected to port c pin 2?

[Tesla DeLorean]

Posted on July 10, 2012 at 20:02

The GCC build is hard faulting, FsFat[_VOLUMES] is NOT being cleared by the C startup code, need to evaluate. Probably needs an ''= { 0 };'', although the comment seems to heap blame/ownership on the compiler.

The Keil based code is working.

[arnold]

Posted on July 10, 2012 at 20:36

so if i'm right it is not the problem of the program you wrote but it's a problem of the compiler.

if i compile i don't get an error. or is that not hard faulting.  if it is a problem of the compiler, how can i go around it so it will work.could you post your working bin file ? so i can flash my board to check if it working :)not that i don't belive you, but i realy wan't to see it myself.

[arnold]

Posted on July 10, 2012 at 21:42

did you only change the linker script ?

if so could you explaine why and what you changed. So i could learn about it.and how did you discover this.Could it be somthing that i could have found as a amateur programmer, which is only working for 2 months with this arm board.

[Tesla DeLorean]

Posted on July 10, 2012 at 22:08

I changed the source so it would perform some head-less operations so that it writes back to the card. I got there by standing up the code in a debugger (Keil in my case), and stepped about in the code to understand what was failing.

You could download a merge tool like WinMerge and observe the changes between the prior release and this. I'd say not that much, just small stuff that was critical. In debugging it became apparent that my hard faults were coming from indirect accesses through memory that the FsFat software assumed were zero. I confirmed what the run time code was clearing, and then tried to understand why. I gleaned most of the information from the MAP file produced by the linker. I also wire-wrapped up a breakout board that I picked up on eBay via Hong Kong so I could finally test on the STM32F4-Discovery instead of the custom board that already has a working MicroSD socket on the PCB. It's hard for me to judge the simplicity/complexity of all this, I've got pushing three decades of micro processor/controller experience, built several wire-wrapped computer systems and boards as a teen, and have a pretty deep involvement in compilers, linkers and loaders.