Help getting started with FatFS please (SPI bus, STM32F4)

[kwheaton]

Posted on September 20, 2012 at 16:53

I've recently switched to using an ST microcontroller and am in need of some assistance getting FatFS to work. I've never worked with FatFS before but it seems to be the go-to module for implementing the Fat file system on microcontrollers. However, when I look at the files involved, it seems to be massively complicated... would someone be kind enough to tell me how to use this and what file(s?) need to be modified to make this work with the SPI bus?

Note:I've found a plethora of examples using the SDIO interface (which is something I'd like to use in the future) as well as an example using the SPI bus (

http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/arm_memcards/index.html#chanfat_stm32

) but there seems to be a lot of extra code inserted and it all becomes a bit overwhelming.

[Tesla DeLorean]

Posted on September 24, 2012 at 19:04

Would the 4Gb size restriction cause the program to get hung in the following loop

Seriously doubt it.

[kwheaton]

Posted on September 24, 2012 at 21:29

Would the 4Gb size restriction cause the program to get hung in the following loop

Seriously doubt it. Got a 2Gb card during lunch and it started working... Pretty surprising to me...

[Tesla DeLorean]

Posted on September 24, 2012 at 22:20

The behaviour of SD/MMC vs SDHC might be the thing to look at. They have different addressing methods.

[kwheaton]

Posted on September 26, 2012 at 17:43

My SDIO breakout board has finally come in and I've managed to cobble together a functioning example based on the library from

http://nemuisan.blog.bai.ne.jp/?eid=192848

. I'd like to strip this down to it's most basic functions and I've already removed the bits for TFT displays and touch screens but there are a few other things I'm not sure if they can safely go or not. For example, There are a few references to ''systick'' that I'm not sure why they are there or what they are for. Additionally, there is a systick interrupt handler that is never accessed. Also, there are a few references to a RTC and I'm not sure if the internal RTC is being used or if the code is even necessary.A few other questions regarding the operation of this code:At the end of SD_WriteBlock and SD_WriteMultipleBlocks a low-level DMA initialization function is called. Would it be more efficient to have this code called at the beginning of the program and only have it called once?When f_read is called to read the contents of a file, is the DMA module used to transfer data to the buffer field of the function call ( f_read(&Fil,

Buff

, sizeof Buff, &br))?

[Tesla DeLorean]

Posted on September 26, 2012 at 18:28

At the end of SD_WriteBlock and SD_WriteMultipleBlocks a low-level DMA initialization function is called. Would it be more efficient to have this code called at the beginning of the program and only have it called once?

It might be, but my observation about STM32 DMA is you want to reprogram it for each transfer, there might be some minimal reconfiguration method, you'd have to experiment. One thing you definitely want to watch though is that the DMA address needs to be 32-bit aligned. This might not be the case with arbitrarily chosen buffers. I personally coded my diskio.c routine to catch these conditions and double-buffer the data.

[kwheaton]

Posted on September 27, 2012 at 18:32

One thing you definitely want to watch though is that the DMA address needs to be 32-bit aligned. This might not be the case with arbitrarily chosen buffers. I personally coded my diskio.c routine to catch these conditions and double-buffer the data.

Forgive my ignorance, but how can I do what you suggest? Currently I am just initializing a buffer in main.c as ''uint8_t Buff[512]''. I'm using an 8-bit array because I will only be reading .bmp files with this program (each byte represents the red, green, or blue content). I'm interested in this because I'm getting some strange results when trying to display an image. The picture tends to come out distorted and skewed and, the more ''busy'' the picture is, the worse the outcome.

[Tesla DeLorean]

Posted on September 27, 2012 at 21:21

I can't speak to the pointer flow through FatFs, but the standard SD_WriteBlock() and SD_WriteMultipleBlocks() expect to be passed offsets into the card as byte addresses, at block boundaries, and buffer addresses that are 32-bit aligned.

I test the low order part of the buffer address to confirm the bottom two bits are zero. If they are not you can either assert(), or use a single block scratch buffer, and then memcpy() a block at a time through this buffer to the SD_Write routines. A technique often referred to Double Buffering, where you move data to/from a buffer physically capable of DMA operation. There are different ways to cause alignment, DWORD Buff[512/4]; works almost universally, some compilers have #pragma pack I'm merely pointing out it's a failure mode which is easy to miss and will take hours to understand. I recall .BMP files being more complicated than R G B, and to be honest I remember Microsoft rastering the line backward (bottom to top), using 32-bit words (RGBQUAD) to express Blue, Green, Red, (Alpha) in the 24-bit formats.