2012-06-30 02:43 PM
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-fatfs2012-07-08 06:22 AM
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.2012-07-08 06:28 AM
2012-07-09 11:36 AM
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.2012-07-09 10:37 PM
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 ?2012-07-10 10:18 AM
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.2012-07-10 10:36 AM
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?2012-07-10 11:02 AM
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.2012-07-10 11:36 AM
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.2012-07-10 12:42 PM
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.2012-07-10 01:08 PM
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.