f_open error 11 (can't find FR_INVALID_DRIVE)

[cleanser23]

Posted on March 02, 2015 at 01:47

My issue is with fatfs in the following code:

retSD = FATFS_LinkDriver(&SD_Driver, SD_Path);if(retSD == 0) { if(f_mount(&sdcard,(TCHAR const*)SD_Path,1) != FR_OK) //works great { Error_Handler(); } else { //HAL_SD_WideBusOperation_Config(&hsd,SDIO_BUS_WIDE_4B); retSD = f_mkfs((TCHAR const*)SD_Path,0,0); //formats just fine, i even took the SD card out and put it in my laptop, formatted 100% ok if(retSD != FR_OK) { Error_Handler(); } else { retSD = f_open(&file,''0:test.bin'',(FA_CREATE_ALWAYS | FA_WRITE)); //trying to just create a file, i tried with and without 0:, in debug I found that is what SD_Path ends up being, I also tried with and without a / at the end.  I always get error 11!!! if(retSD != FR_OK) { Error_Handler(); } } } }After stepping through my code for a few hours, I have also found a strange error that occurs in the middle of the f_open below:if (res == FR_OK) { INIT_BUF(dj); res = follow_path(&dj, path); /* Follow the file path */ dir = dj.dir;INIT_BUF(dj) simply calls malloc(size) where size is about 514 (2*some buffer size in ffconf.h)I certainly have this much memory available...but when it returns the function f_open jumps to the end with a return code error (optimization is off so I can see every step, but this still happens...)Any pointers? #stm32-fatfs-f_open

[cleanser23]

Posted on March 02, 2015 at 01:58

Wow I feel silly, the error is NOT error 11 it's error 0x11, working buffer could not be allocated, I think the issue is that malloc is not working...what should I do (i'm searching as we speak, so I am looking as well, I'll post if I find my solution)

[cleanser23]

Posted on March 02, 2015 at 02:34

Figured it out, I failed to increase the heap and stack sizes (stack size causes hardfaults when there is too much statically allocated stuff, heap size makes malloc not work)

Brandon

[cleanser23]

Posted on March 02, 2015 at 02:48I'm so close...I can create the file, but when I try to write to it, I write 0 bytes and get a /* Could not allocate a new cluster (disk full) */error and no bytes are written.I thought it wrote when I stepped, through, but I was wrong.Sorry for my spam

[Tesla DeLorean]

Posted on March 02, 2015 at 03:23

Sounds like either it's not reading the FAT structures properly, or failing on the write side.

But so far I have no idea what STM32 this is, or what tool chain. Keil has stack/heap allocations in startup_stm32xxx.s

[cleanser23]

Posted on March 02, 2015 at 03:49

clive,

sorry about that, this is on keil, I have already increased the size of the stack and heap, which fixes my hard faults, and I am programming an stm32f4xx processor. I also have a weird new bug, I was trying to match my code as much as possible to the ffconf included from ST as an example, so I configured LFN to be 0 (disabled).  Now I am getting hard faults again!!! how is this possible?  Right now my stack is 0x800 and my heap is 150kThanks

[Tesla DeLorean]

Posted on March 02, 2015 at 04:49

You'd want to understand the cause of the Hard Fault's by using a handler capable of displaying the machine/register states at the fault. Joesph Yiu has published several examples. Randomly guessing the cause isn't one I'd recommend.

Is a 2K stack size sufficient? Hard to say, you could do some static analysis of your code and call tree and understand how much it needs. You could make the stack a lot bigger, and fill it with a recognizable character, then measure the used depth periodically.It's also important to thoroughly test the SDIO read/write functionality outside of FatFs. The real cause of failure is hard to determine at the f_open/f_close level. You might want to instrument the diskio.c functions, and return status. The DMA has expectation of 32-bit word alignment of it's buffers.

[cleanser23]

Posted on March 02, 2015 at 05:06

Clive,

I don't see why 2k would be enough when LFN is enabled and not when it is disabled, I've been stepping through everything and f_open works fine now, it even creates the file, so I know my read/write sdio functions must work, even in 4 bit mode.Now I am getting errors because I can't allocate a block, it thinks the sd card is full

[cleanser23]

Posted on March 02, 2015 at 05:46

Well increasing stack size to 4k stopped the hard faults from happening, though i have no idea why they would happen when LFN is disabled, perhaps that mode puts a bunch of stuff on the stack,

I also tried reading a file itself that I created on a computer, but that wouldn't read the same why I couldnt write, even though it could open the file/create the file.So in short, I can read/write to the SD card, but FATfs doesn't want to read and write to files, though it has no problem making them.any ideas?

[cleanser23]

Posted on March 02, 2015 at 06:14

Figured it out, nothign was wrong at all, my counter for bytes read/read was only 8 bit

I am a fool :(