STM32F103+SDIO+FatFS fault issue

[drew]

Posted on August 16, 2016 at 04:31

I have a project generated by ST32CubeMX that uses the SDIO hardware to talk to SD cards that is generating a hard fault when doing any sort of file access.  I'm not sure exactly what is going on since the project is pretty vanilla, just generated by CubeMX and imported into an eclipse project.  The system uses FreeRTOS with a single task running a basic delay loop routine.

The sequence of events is as follows:

#include ''ff.h''

//........In main.c

// All CubeMX init functions called for SDIO, clock, etc

//........Before loop

MX_FATFS_Init();

if(f_mount(&FatFs,'''',0)!=FR_OK)

    error=true

    

//........Inside loop

sprintf(fileName,''Test%d.txt'',count++);

result=f_open(&log_file, fileName, (FA_WRITE|FA_CREATE_NEW));

if(result==FR_OK)

{

    error=true;

}

f_close(&log_file);

// end

As soon as the f_read() is called a hard fault is triggered.  I've removed the FatFs code from the test and just did SDIO block read functions and I did not get this fault.

Has anyone else run into this situation?  Am I missing an initialization call or parameter for FatFs?

I've uploaded a test Eclipse CDT project that has the error, all code is from STM32CubeMX except for the task functions in main.c

FreeRTOS V8.2.3

FatFs 

R0.11 (

32020)

Thanks

[troy1818]

Posted on August 16, 2016 at 07:02

Hi,

I do not know if this is your problem but you need to write the glue layer for Chan fatFS yourself. Also, make sure that the file descriptor is allocated by you.

Perhaps this thread can be helpful

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a//my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/%5bFATFs%5d%20Opening%20file%20on%20USB%20stick%20returns%20FR_DISK_ERR&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=82

In any case it would be good to look in a debugger and at least see the backtrace for when the hard fault happened. On a side note I cannot see any f_read in your pasted pseudo code. Could you disclose the real code for this problem ?

[drew]

Posted on August 16, 2016 at 11:03

rygelxvi,

I have glue functions, the file descriptor is allocated correctly. The debugger shows an address that can't be shown, so I'm not sure where the fault is located. I have a feeling it has something to do with interrupts, so I added interrupt definitions for all vectors with 'while(1) nop()' to catch anything I missed however none of them are triggered.

The full project is attached on the post, I will re-attach here.

As a test I slowed the clock rate of the SDIO down to the lowest level and read and write 512 blocks to the SD card to see if there is an issue with the SDIO driver. The following code passes each time. I know this will delete the partition table, but it is a good test of the low level functions

result = BSP_SD_Init();
if
(result != MSD_OK)
asm(
''nop''
);
// Fill buffer
for
(x=0;x<512;x++)
{
tmp = (uint8_t)x;
m_scratch[x] = tmp;
}
// Write
for
(x=0;x<1000;x++)
{
result = BSP_SD_WriteBlocks(m_scratch, x*0x200, 512, 1);
if
(result != MSD_OK)
{
asm(
''nop''
);
}
else
{
while
(BSP_SD_GetStatus()==SD_TRANSFER_BUSY);
}
}
nop();
// Read
for
(x=0;x<1000;x++)
{
memset
(m_scratch,0,
sizeof
(m_scratch));
result = BSP_SD_ReadBlocks(m_scratch, x*0x200, 512, 1);
if
(result == MSD_OK)
{
// Compare
for
(c=0;c<512;c++)
{
tmp=(uint8_t)c;
if
(m_scratch[c] != tmp)
{
// Invalid data
asm(
''nop''
);
}
}
}
else
{
asm(
''nop''
);
}
}

What is very interesting is that this code executes fine, however adding some FatFs function calls below it will generate a HardFault in the BSP_SD_WriteBlocks calls above!

{
FATFS FatFs;
FRESULT fresult;
DIR log_dir;
int
y;
MX_FATFS_Init();
fresult = f_mount(&FatFs,
''''
,0);
if
(fresult!=FR_OK)
asm(
''nop''
);
fresult = f_opendir(&log_dir,
''''
);
if
(fresult!=FR_OK)
asm(
''nop''
);
}

Thanks

________________

Attachments :

CubeMXFatFsTest.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0sU&d=%2Fa%2F0X0000000bew%2F8dcu334MHjqWujULrpCWoTHCeiGKADdLbPyB.maI7uA&asPdf=false

[troy1818]

Posted on August 16, 2016 at 11:12

I guess your stack is being corrupted. Try and increase the stack size for your process.

I think that you can choose the allocation type for fatFS in some configuration file somewhere. I think the default setting is that the library will allocate on the stack as opposed to the heap. This can also be changed of course in order for your process to allocate less stack.

[drew]

Posted on August 16, 2016 at 13:01

Well after cranking away all day I think I've identified the main fault issue.  It appears that FatFs generates a fault if you are using local variables inside a FreeRTOS task function.  Moving all the FIL, DIR and FATFS instances to module scope solves the problem.  This issue was compounded by the fact that the cards I am using don't communicate reliably at the 24MHz clock speed of the SD spec, so my first tests still had issues with module scope functions.