FatFS initialization on F072

[Krystof Vanek]

Posted on May 13, 2017 at 16:26

Hello,

I'm trying to port CubeMX repository example for uSD card on STM32F072-EVAL to NUCLEO-F

For some reason I get error out of functionf_mount(...) which returns 11 (The logical drive number is invalid).

Also I can't see how is ff.c and diskio.c connected to the used driver sd_diskio.c.

Did anybody else encounter this problem?

Thank you very much for help.

#fatfs #sdcard #spi #stm32f072 #sd-card Note: this post was migrated and contained many threaded conversations, some content may be missing.

[developer2]

Posted on May 13, 2017 at 20:58

Hi,

what is exact syntax of your f_mount command ?

are you using something like : f_mount('0:/'); or f_mount('1:/'); ?

for the number in brackets ... you could find it by searching call of function: FATFS_LinkDriver

it was like this when i used CubeMX generator ...

[Krystof Vanek]

Posted on May 13, 2017 at 22:54

This syntax is

f_mount(&SDFatFs, (TCHAR const*)SDPath, 0);�?

SDPath is string containing {{179} {58} {47} {0} given from FATFS

_LinkDriver.

Your reply gave me an idea to try setting SDPath[0]=0.With such path it gets passthe f_mount function but f_mkfs exits with 3 -The physical drive cannot work.

[developer2]

Posted on May 14, 2017 at 09:20

currently you have in your SDPath variable: '|:/' ... which wrong ... first character should be number ... '0' or '1' or ...

value of 179 in ascii means '|'

[Krystof Vanek]

Posted on May 15, 2017 at 15:15

Yes.. it seams like it, the error code states it too. However, as I wrote, when I try to change it to '0' manually, mkfs still cant make it. Maybe the right number has to be returned by the function

FATFS

_LinkDriver, but how could that be done?

For better insightI'm attaching the whole project.

________________ Attachments : Podlaha-dev.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hyec&d=%2Fa%2F0X0000000bAj%2Fj5.DxuV5C_e0p_Ez6NqTk5jti.UkaVpPHyDwb5BNsVo&asPdf=false

[developer2]

Posted on May 15, 2017 at 17:42

Hi,

regarding your project, sequence of your functions:

main.c :

MX_ADC_Init()

MX_FATFS_Init() --> goes into fatfs.c and there is implementation:

void MX_FATFS_Init(void): retUSER = FATFS_LinkDriver(&USER_Driver, USER_Path);

so here in variable USER_Path is placed identification that was generated by function FATFS_LinkDriver

then back to main.c

....

then: FATFS_LinkDriver(&SD_Driver, SDPath);

so you have to have 2 FAT devices registered ... first identification is in USER_Path, second is in SDPath ...

so at this point registered drivers are:

'0:/' = dummy CubeMX driver named USER_* registered from fatfs.c

'1:/' = SD registered from main.c

simply ... try f_mount with '1:/' ... :)

[Krystof Vanek]

Posted on May 15, 2017 at 22:00

Hello,

Thanks a lot! That is, of course, a huge mistake. I completely missed CubeMX generated the init function.

I believe trying to mount with '1:/ ' wouldn't work as the project specifies 1 logical volume limit. Also the Cube generated functions implements the User specified driver which I don't want to specify  So.. I commented out the 

MX_FATFS_Init() and now the system links the driver properly and mounts!

However there is another problem.. both f_mkfs and f_open seems to hang. Ill try to figure out tomorrow as this probably could also be a hardware issue.

Thank you a lot for the progress!

[developer2]

Posted on May 15, 2017 at 22:10

i could propose only 3 things:

- try to format FAT on PC and check out on STM

- try to use DMA on SDIO

- try faster SD card :) ...

[Krystof Vanek]

Posted on May 18, 2017 at 21:23

Hi, thank you for suggestions. 

Unfortunately I can't try SDIO as the chip doesnt have one. I slowed down the SPI significantly and made sure there is no error on the bus. There actually were some bugs. However now the SD card inits just fine.The problem is still with writing to the card (or anything else).

For some reason in function  BSP_SD_ReadBlocks, in heating_SD.c, when trying to read first 512 bytes of the card allocation of RAM fails (malloc returns NULL) which makes the whole f_open process to fail.

[developer2]

Posted on May 18, 2017 at 21:34

Hi,

now i see :( ... i have only STM32F4 or STM32F7 ... and both have SDIO ... i didn't realize that F0x2 may not have SDIO ...

and regarding malloc failure i propose to write new topic and mention malloc error in relation to compiler or compiling environment ...

Kind regards,