STM3210E-Eval + sdio + fatfs problem

[melanie]

Posted on July 10, 2014 at 11:01

Hi,

I would like to be able to read files on the microSD card 2GB with the stm3210E-eval board. I implemented the diskio.c functions for FatFs in read only. When I call the f_open() function I always got an FR_NO_FILE error even if the file exists. And when I call f_readdir() the fno.fname[0] is always equal to 0. Do you have any idea why? Here comes the code when I call the functions.

err = f_mount(&FatFs, 
''''
, 0);
if
(err == FR_OK){
/* Open root directory */
err = f_opendir(&dir, path);
if
(err == FR_OK){
/* Read directory */
err = f_readdir(&dir, &fno);
if
(err == FR_OK && fno.fname[0]!=0){
STM_EVAL_LEDOn(LED1);
fn = fno.fname;
}
}
/* Close directory */
err = f_closedir(&dir); 
if
(err == FR_OK){
}
/* Open a text file */
err = f_open(&file, 
''0:/message.txt''
, FA_READ);
if
(err == FR_OK){ 
STM_EVAL_LEDOn(LED2);
}
else
if
(err == FR_NO_FILE){
STM_EVAL_LEDOn(LED3);
}
else
{
STM_EVAL_LEDOn(LED4);
}
/* Close the file */
err = f_close(&file);

#fatfs #sdio #stm3210e-eval

[frankmeyer9]

Posted on July 10, 2014 at 12:51

Do you have any idea why?

Perhaps it fails already on the lowest level, which directly accesses the hardware. Have you tried to debug ? Have you verified the signals with a scope ?

err = f_open(&file, 
''0:/message.txt''
, FA_READ);

That ''

0:/

'' part of the filename looks rather unfamiliar to me. I'd bet it is wrong ...

[melanie]

Posted on July 10, 2014 at 13:53

Have you tried to debug ?

What do you mean by debug? I am currently using IAR Embedded Workbrench IDE with an I-Jet probe.

With a step by step procedure I haven't found were the problem comes from. Could it be in the diskio.c ?

Have you verified the signals with a scope ?

No, which signals should I verify?

That ''

0:/

'' part of the filename looks rather unfamiliar to me.I'd bet it is wrong ...

I found that 

''

0:/

''

 represents the device I'm using, it could be 

''

1:/

''

 or 

''

2:/

''

. But I have only one device connected. 

Anyway, without the 

''

0:/

''

 I've got the same result.

 

[frankmeyer9]

Posted on July 10, 2014 at 17:08

What do you mean by debug? I am currently using IAR Embedded Workbrench IDE with an I-Jet probe.

With a step by step procedure I haven't found were the problem comes from. Could it be in the diskio.c ?

This is somehow self-contradicting. If unsure, read the IAR help/documentation on how to debug an application. The FatFS functions return proper error codes, it is not really difficult to drill down to the source of the problem.

No, which signals should I verify?

However your SD card adapter is conneted to your MCU. The tread title suggests the SDIO peripheral. Check the schematics. I had once ported FatFS to the F3-discovery, and needed to write the low-level SPI functions (for FatFS) myself.

I found that 

''

0:/

''

 represents the device I'm using, it could be 

''

1:/

''

 or 

''

2:/

''

. But I have only one device connected. 

Anyway, without the 

''

0:/

''

 I've got the same result.

  In the above mentioned implementation, I had given a plain filename string like ''file.txt'', which of course had to exist in the root folder of the SD card (single partition).

[melanie]

Posted on July 10, 2014 at 17:42 The original post was too long to process during our migration. Please click on the provided URL to read the original post. https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I6oD&d=%2Fa%2F0X0000000bvv%2FVy9E.6ln5uTX70xALFGoWDqoZBkMvCkCnOgE_YhcaiE&asPdf=false

[Tesla DeLorean]

Posted on July 10, 2014 at 18:52

I have got a library for the low-level SDIO functions named 

stm32_eval_sdio_sd 

it allows me to read blocks. I just wrote the device control interface for FatFs using that library.I think the problem comes from this part. This is what I wrote: Lifting code from an F4 implementation might not be the way to go unless you fully understand the underlying driver code. If FatFs is not finding your file, you should perhaps review the data in the sectors read with a little more rigor.

[melanie]

Posted on July 11, 2014 at 09:40

Lifting code from an F4 implementation might not be the way to go unless you fully understand the underlying driver code.

Do you mean the library I use is for F4 or the code I show you before. I'm pretty sure the library is correct because it's given for my board.If FatFs is not finding your file, you should perhaps review the data in the sectors read with a little more rigor.Thanks for the hint I will look at it.

[Tesla DeLorean]

Posted on July 11, 2014 at 13:57

It does look awfully familiar....

[melanie]

Posted on July 11, 2014 at 14:15

I thought that the differences between the STM32F4 and STM32F10 would be in the implementation of the SD_ReadMultipleBlock() and SD_WriteMultipleBlock() functions. I guess I was wrong.

Moreover, the example given to use the sdio on the board is the same. Here comes one of the function given.

void

SD_MultiBlockTest(

void

)

{

/*--------------- Multiple Block Read/Write ---------------------*/

/* Fill the buffer to send */

Fill_Buffer(Buffer_MultiBlock_Tx, MULTI_BUFFER_SIZE, 0x0);

if

(Status == SD_OK)

{

/* Write multiple block of many bytes on address 0 */

Status = SD_WriteMultiBlocks(Buffer_MultiBlock_Tx, 0x00, BLOCK_SIZE, NUMBER_OF_BLOCKS);

/* Check if the Transfer is finished */

Status = SD_WaitWriteOperation();

while

(SD_GetStatus() != SD_TRANSFER_OK);

}

if

(Status == SD_OK)

{

/* Read block of many bytes from address 0 */

Status = SD_ReadMultiBlocks(Buffer_MultiBlock_Rx, 0x00, BLOCK_SIZE, NUMBER_OF_BLOCKS);

/* Check if the Transfer is finished */

Status = SD_WaitReadOperation();

while

(SD_GetStatus() != SD_TRANSFER_OK);

}

/* Check the correctness of written data */

if

(Status == SD_OK)

{

TransferStatus2 = Buffercmp(Buffer_MultiBlock_Tx, Buffer_MultiBlock_Rx, MULTI_BUFFER_SIZE);

}

if

(TransferStatus2 == PASSED)

{

STM_EVAL_LEDOn(LED3);

}

else

{

STM_EVAL_LEDOff(LED3);

STM_EVAL_LEDOn(LED4);

}

}