Welcome,
Is there anybody who is using SD/microSD card by SPI interface on STM43F4xx? I think that latest updates changes something and it's not working anymore. But I have only 2 PCB from one project and I don't have time for tests now - I need working program ;/
Situation is like that: - STM32F429; 32MB ExtRAM, GUI (LCD), 2xSD (SDIO, SPI4), USBFS (host/device), blebleble... - 2 devices; hardware is OK.
First program was created about year ago (~July 2015) was working correctly (it has to because I was using card by SPI). It was compiled with: - ARM:CMSIS: 4.2.0 - Keil:MDK-Middleware: 6.2.0 - Keil:STM32F4xx_DFP: 2.2.0
Because of some PC malfunction from that time I have only compiled data in my format (I can flash my boards and it's working). All source is from archives and (except SPI) it's working correctly. I don't have also Keil installation with exactly the same set of files. But from project file I read libraries versions.
In that year I created some other programs for that board but I didn't used SD by SPI so I don't know when it stopped working.
Now I need to recompile old code (some changes) and - doesn't matter what I do - card is not working (SPI card). I tried everything - even deleting all other libraries versions from Keil Packs. All other things are working OK (card by SDIO, USB host, USB device, GUI, RTOS...) and it doesn't matter on which libraries I'm using. I even tried to delete all code and leave just SD test:
int main(void) { fsStatus fs; FILE *f; fs = finit("M0:"); if(fs == fsOK) { fs = fmount("M0:"); if(fs == fsOK) { f = fopen("M0:\\aaa", "w"); fwrite(&fs, 1, 1, f); fclose(f); } } while(1); }
I have found way out; it's temporary and incomplete: 1. set up libraries to: - ARM:CMSIS: 4.5.0 (doesn't matter) - Keil:ARM_Compilet:1.0.0 - Keil:MDK-Middleware: 7.0.0 (doesn't matter) - Keil:STM32F4xx_DFP: 2.4.0 (<= 2.4.0 is working; newer - NOT)
2. in RTE_Device.h disable for SPI (SPI4 in my project) 3. run APB2 clock 2x slower Normally I work on 168MHz, which gives APB2 max clock 84MHz. But I need to run it on 42MHz.
And it's working now. BUT - only normal SD cards. SDHC cards are NOT working.
One of my PCB is old and it was working with problematical program. And, as I wrote - it was working. So hardware should be OK. As for me, STM32F4xx_DFP package is suspected. But I don't have enought hardware to check it. Also it would be strange - if it is broken for some time and nobody noticed it...
So, firstly I would like to thank you if you managed to read my horrible english ;p Second - if anybody is using SD card on SPI interface on STM43F4xx please write something (libraries, configuration, whatever).
Aha - I have checked all items like stack, heap, clocks...
Hi,
To be honest - I've got idea how to debug SPI driver ;)
But probably I have found error: (and why I was thinking that is stopped working)
If card is formatted on PC in FAT32 (cluster size doesn't matter) and there is nothing on it (card is empty; no files or directories) fmount hangs up. But it's not dead. It's working correctly but very long - on one of my cards it was about 3 minutes!
When there is something on card (even empty file or directory) - fmount is working correctly. Also I tried some scenarios:
legend: OK - OK BAD - fmount works too long
1. Card formatted on PC. Empty. -> BAD,
2. Card formatted on PC with one empty file. -> OK
3. Card formatted on PC; with one empty file (I'm sure that it was written on card) which was deleted. -> BAD
4. Card from point #2 which was formatted on device (fformat works only after fmount succeed) -> BAD
5. Card from point #2 which was formatted on device (fformat) and just after that I created file (still on device) -> OK
6. Card from point #2 which was formatted on device (fformat) and just after that I created file (still on device) and delete it -> OK
I have never wait that long because fmount hang up all device (with RTOS). It means that normally watchdog will kill it. In other way: for end-user device it's not working.
And now some other informations: - I have tested it on STM32F4xx (STM32F429II); I don't have now something more with card through SPI, - FAT12/FAT16 is always working correctly (even if I format 4GB card with FAT16), - problem is only with FAT32 (even when I format 256MB card with FAT32 - it's still not working), - full format doesn't help, - I tried standard Windows 7 format, SDFormatter and HP USB Disk Storage Format Tool), - I have tried cards: 1x microSD Nokia 256MB 1x microSD HC 4GB class 2 4x microSD HC Goodram 4GB class 4 2x microSD HC Goodram 8GB class 4 1x microSD HC 8GB class 6 1x microsd HC Goodram 32GB class 10 - memory: I checked all buffers, stacks and cache sizes (all are more than enought); my PCB has 32MB external memory
And that's why I was thinking it was working correctly with older libraries. I just have never wait that long and have always used formatted cards...
There is nothing I can do more. Also I don't know what to check more.
What you describe is most likely due to the fact, that Windows formatters do not create FS Information Sector - you can read more about it here: en.wikipedia.org/.../Design_of_the_FAT_file_system
FS Information Sector contains information about free space on the volume. By default, after format, this information is not written (byte offset 0x1EC in table on Wiki), therefore it must be determined - and this is what takes so long. Since free space is determined by scanning FAT table, this proces will take longer on larger SD cards.
What is the SPI clock frequency on your system? Did you verify and measure it? If it is too low, this process can take a very long time.
There is also STM32F4xx DFP V2.7.0 available on MDK5 Software Pack download page (http://www.keil.com/dd2/pack/#), maybe you can try with this one?
I tried this: - ARM:CMSIS: 4.5.0 - Keil:MDK-Middleware: 7.1.0 - Keil:STM32F4xx_DFP: 2.8.0 - clean Keil installation
and it's not working.
Clocks are OK (330..375kHz) but fmount returns fsMediaError. Old libraries works as I wrote earlier.
I've got no idea what's wrong.
I have a similar problem with LPC1768. Have you managed to solve it somehow?
Note that the last reply here is over 3 years old - so unlikely people are still listening.