STM32 + SD Card

[mailmail9116]

Posted on December 27, 2012 at 12:27

Hi,

I am trying to initialze my SD card,for some reason i cannot create\open a file,this problem raises the following question : am i obligated to use the fatfs library f_open, or can i use the regular fopen\ifstream etc... to work with files ? .. Here attached a code snippet of what ive done :

FATFS MSD_fatfs;


#include ''stm32f4xx.h''

#include ''stm324xg_eval.h''

#include ''stm324xg_eval_sdio_sd.h''

#include ''ff.h''


int
main(
void
)

{ 

if
(SD_Init() == 0)

{

if
(SD_GetStatus() == 0)

{

if
(f_mount(1, &MSD_fatfs ) == FR_OK )

{

FILE *fp_ = fopen(
''1:/mm.txt''
,
''w''
);

if
(fp_!=NULL)

{

fclose(fp_);

}

}

}

}

}

Thanks Michael

[Tesla DeLorean]

Posted on December 27, 2012 at 20:10

If you use FatFs you'll need to use that libraries f_open(), etc or provide your own abstraction layer.

For FatFs you'd want to look at the error codes returned to understand failure conditions, and perhaps instrument the routines in diskio.c to see what gets called, and why that layer might be failing. Embedded typically doesn't provide a fully formed STDIO library because each board is unique, and doing file io is more of the domain of an operating system. You can certainly get your own OS, devices and file systems, but these usually entail more time/expense. Some toolchains provide hosting for STDIO.

[mailmail9116]

Posted on December 30, 2012 at 15:23

Hi,

I am having issues initializing the SD Card(this is part of the fatfs f_open function flow) , i am constantly reciving an un expected interrupt while trying to send read multiple block command. The weird thing is that the same code works correctly on the evaluation demo,but here no luck,see below the problematic code part ,any ideas on fixing the issue will be mostly appreciated :

SD_Error SD_ReadMultiBlocks(uint8_t *readbuff, uint32_t ReadAddr, uint16_t BlockSize, uint32_t NumberOfBlocks)
{
SD_Error errorstatus = SD_OK;
TransferError = SD_OK;
TransferEnd = 0;
StopCondition = 1;
///A lot of code here ..................
/*!< Send CMD18 READ_MULT_BLOCK with argument data address */
SDIO_CmdInitStructure.SDIO_Argument = (uint32_t)ReadAddr;
SDIO_CmdInitStructure.SDIO_CmdIndex = SD_CMD_READ_MULT_BLOCK;
SDIO_CmdInitStructure.SDIO_Response = SDIO_Response_Short;
SDIO_CmdInitStructure.SDIO_Wait = SDIO_Wait_No;
SDIO_CmdInitStructure.SDIO_CPSM = SDIO_CPSM_Enable;
SDIO_SendCommand(&SDIO_CmdInitStructure);
// Here i am having the interrupt and the program jumps to infinite loop .
errorstatus = CmdResp1Error(SD_CMD_READ_MULT_BLOCK);
if
(errorstatus != SD_OK)
{
return
(errorstatus);
}
return
(errorstatus);
}

[hfs99]

Posted on December 30, 2012 at 18:28

Sounds to me like you nearly have it nailed down. Unless you have other time-sensitive stuff going on, you can step into SDIO_SendCommand() and find out which line causes your exception. If necessary you can reset and repeat, stepping through just that line in assembly mode. Once you see exactly what causes the exception you may be able to figure out the root cause.

The ST-supplied routines are way way WAY better than trying to start from scratch (!), but it has been pointed out that they are not bullet-proof in error conditions. (sorry - too lazy to search - I know how my searches here always wind up.) You could report the type of exception, but I doubt that will be any use to anyone without knowing which line causes the problem. -Hugh

[mailmail9116]

Posted on December 30, 2012 at 18:49 Hi, Well i know it the

SDIO_SendCommand(&SDIO_CmdInitStructure);

function that makes the trouble,it crashes just after the update of the CMD register ,also i read in some other thread about the DMA initialization issue,so i fixed it and move the DMA initialization before the send command,still the same issue. The SDIO is the only peripheral that i use for now,and the weird thing is that the same code works just fine on the evaluation firmware .

[Tesla DeLorean]

Posted on December 30, 2012 at 20:34

It half sounds like you're not servicing the SDIO or DMA interrupt, and the processor is dumping you into the general unspecified interrupt vector point with a while(1).

In stm32f4xx_it.c (or wherever)

/**
* @brief This function handles SDIO global interrupt request.
* @param None
* @retval None
*/
void SDIO_IRQHandler(void)
{
/* Process All SDIO Interrupt Sources */
SD_ProcessIRQSrc();
}

[mailmail9116]

Posted on December 31, 2012 at 06:59 Thanks Clive,it was really the problem !

[laiviethai]

Posted on January 08, 2016 at 10:51 Hello everyone,I have a problemwith sd card, function f_open in file ff.c put in function mainthe entire program is not working, help me!,all help are very welcome! ________________ Attachments : __SD-SPI.rar : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0vK&d=%2Fa%2F0X0000000bg7%2FxkekR8.MvrORJhyC8nYhJrLyQ_XKPyPhWVa9Uprc5Ig&asPdf=falseSCHEMA_TMe-STM32F103.pdf : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0wv&d=%2Fa%2F0X0000000bg2%2FQRtGBsk7oM62Ob_UvHKOwIBhJATSc4buTt9YiBENxWE&asPdf=false

[Tesla DeLorean]

Posted on January 08, 2016 at 14:07

Sorry, this isn't a board I have, you'll need to review and test the function of the underlying routines that access blocks from the media, and prove they work properly before integrating them with FatFs. As suggested earlier in the thread you might want to instrument the functions in DISKIO.C, or your SD SPI implementation, to see what it happening.