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 20, 2012 at 19:52

I'd perhaps start by looking at the STM32L example which uses SPI to MMC/SD cards, and uses FatFs. Wrong chip, I know, but should be portable enough.

STM32L152-EVAL_FW_V1.2.0\Utilities\STM32_EVAL\STM32L152_EVAL\stm32l152_eval_spi_sd.c FatFs is abstracted from the low level stuff by the code in diskio.c, so figure out the SD sector read/write functionality first. Also be cognoscente that most of the ST implementations work on cards less than 4GB as they use 32-bit byte addressing, rather than sector/block addressing 

[kwheaton]

Posted on September 20, 2012 at 20:25

Okay, from what I can gather, I'd need to pluck out and modify the following functions from the following files (and necessary #defines/variables):

stm32l152_eval.c SD_LowLevel_DeInit() SD_LowLevel_Init() stm32l152_eval_spi_sd.c all functions (?)and lastly initialize the SPI functions on the GPIO?Regarding the 32-bit addressing: I see the 32-bit address fields in the function calls. Is this the restriction that is putting the 4Gb cap on the SD card? Can one get around this restriction by formatting the card to only use slightly less than 4Gb? Are there other implementations that aren't restricted by this address range?

[Tesla DeLorean]

Posted on September 20, 2012 at 20:52

Yeah, pretty much that, and whatever L1 vs F4 differences there might be.

I've ported the SDIO stuff from the STM32xxG-EVAL boards to the STM32F4-Discovery, to support MSC (USBSTOR) and FATFS off a MicroSD card, and FIXED the 4GB issues across the source. Projects have been posted against the forum. I've used 16 and 32GB MicroSD cards via USB. Honestly I haven't bothered with SPI, as it's even slower than SDIO, which itself isn't particularly stellar.

[kwheaton]

Posted on September 20, 2012 at 21:03

I'm aware that SPI isn't the best implementation but it's the only interface I have at the time (limited by the breakout board I have...). I will be using SDIO in the future though. Did you use a similar process as what I described above to port those examples over? Was the use of SDIO overcome the addressing restrictions or was there more involved?

[Tesla DeLorean]

Posted on September 20, 2012 at 21:23

The EVAL boards are a lot richer in hardware than the DISCOVERY boards, I had to claw out a lot of junk related to the LCD display. The discovery also doesn't come with an RS232 port, I've hung a serial connection off USART2.

The large card issues are covered somewhat here[DEAD LINK /public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Where is the UsbMassStorage Examples Supt for stm32f4xx&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=617]https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2FWhere%20is%20the%20UsbMassStorage%20Examples%20%20Supt%20for%20stm32f4xx&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=617 FatFS, 4GB, and ports here[DEAD LINK /public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/STM32 sdio sdhc 4gb problem&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=102]https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2FSTM32%20sdio%20sdhc%204gb%20problem&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=102 I've got other projects in Keil too

[kwheaton]

Posted on September 20, 2012 at 22:12

Thanks for the links! I'm glad someone else thinks the search function isn't worth the effort in this forum...

Just so I understand: the example linked in the second thread uses the SPI port and, if I grab diskio.c and use stm32l152_eval_spi_sd.c for the low-level transmit/receive and wish on a falling star, I should have a working example (provided my breakout board is wired correctly and I've made the changes for F4)?

I feel like I'm about to open a can of worms, but can I just enable the clocks to the SPI module or do I need to be aware of the clock speed that module is using?

[Tesla DeLorean]

Posted on September 20, 2012 at 23:10

No, I don't think any of them explicitly address the use of SPI. The SDIO starts up in 1-bit mode, and later switches speed, and to 4-bit mode.

The STM32L152_EVAL I cited earlier is where I'd start if I had a horse in this race. It implements the SPI/SD abstraction with an SD_ReadBlock/SD_WriteBlock function. It has a FatFS/diskio.c implementation compatible with the aforementioned card access code. You mentioned the porting steps earlier, and I generally agreed with those. Start with the SPI/SD code, the FatFs code should just pull into the project later with no modification. This is all with the ST code track, I am aware there is another SPI/SD/FATFS track out there for the STM32 that Martin Thomas, et al pulled together. I've gone the ST route because it is generally a more unified solution across the various STM32 platforms, but it's more of a proof of concept implementation, and not as robust as I might like.

[kwheaton]

Posted on September 21, 2012 at 20:19

Would the 4Gb size restriction cause the program to get hung in the following loop (found in the function SD_GoIdleState() as called at the end of SD_Init())?

/*----------Activates the card initialization process-----------*/
do
{
/*!< SD chip select high */
SD_CS_HIGH();
/*!< Send Dummy byte 0xFF */
SD_WriteByte(SD_DUMMY_BYTE);
/*!< SD chip select low */
SD_CS_LOW();
/*!< Send CMD1 (Activates the card process) until response equal to 0x0 */
SD_SendCmd(SD_CMD_SEND_OP_COND, 
0
, 
0
xFF);
/*!< Wait for no error Response (R1 Format) equal to 0x00 */
}
while (SD_GetResponse(SD_RESPONSE_NO_ERROR));

I see that I am getting some activity on the MISO line and SCK, MOSI, and CS all appear to be doing what they should. Also, I've slowed the clock down to about 105kHz (when in doubt, slow it down).

[kwheaton]

Posted on September 24, 2012 at 17:14

Bump