2014-07-10 02:01 AM
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
2014-07-10 03:51 AM
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 ...2014-07-10 04:53 AM
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.
2014-07-10 08:08 AM
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).2014-07-10 08:42 AM
2014-07-10 09:52 AM
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.2014-07-11 12:40 AM
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.2014-07-11 04:57 AM
It does look awfully familiar....
2014-07-11 05:15 AM
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);
}
}