cancel
Showing results for 
Search instead for 
Did you mean: 

FreeRTOS + FatFs (STM3240G) -> FR_DISK_ERR

ariel2
Associate II
Posted on December 04, 2014 at 14:54

Hello,

I've modified FatFs_uSD_RTOS example to write in a loop (32k files), which works fine on its own (Task SDCardStream()). When I add another task Process() which only has a calculation loop:

static
void
ThreadProcessing(
void
const
*argument)
{
portTickType NextProcess, tmp;
for
( ;; )
{
tmp = xTaskGetTickCount();
if
((tmp % 100 == 0) && (tmp != NextProcess))
{
NextProcess = tmp;
for
(
int
i = 0; i < 13186; i++)
{
res += 
sqrt
((i*i) / 37);
}
}
vTaskDelay(1);
}
}

SDCardStream() will fail with the errorFR_DISK_ERR.

The only way to resolve that error is by wrapping all of FatFs functions with a critical question, e.g.:

taskENTER_CRITICAL();
f_mkdir(&filename[0]);
taskEXIT_CRITICAL();

Did anyone experience that? Do you have any idea what can cause this? Any lead would be appreciated :) #freertos #fatfs #stm3240g
7 REPLIES 7
ariel2
Associate II
Posted on December 06, 2014 at 17:27

To simplify it ThreadProcessing is now reduced to:

static
void
ThreadProcessing(
void
const
*argument)
{
for
( ;; )
vTaskDelay(1);
}

</p>

After doing many more tests I saw that even running the SDCardStream() task without any other task, it will fail, it just takes more time.

Been tweaking all of the configurations you mentioned and running the test in the same config several times (as it can even complete successfully (1024 files) in one test and then fail after 10 files in another run)

***The same code, with the same driver, works without the RTOS. I ran several tests of 32k files each.

I am sure its something trivial that I am missing (like Stack Overflow that you suggested)..

</div>

Posted on December 06, 2014 at 22:54

I'd probably look at the SD and DMA interrupts. The SD peripheral code is probably not thread safe or reenterant, so you'd want to serialize access with a mutex or something.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
ariel2
Associate II
Posted on December 16, 2014 at 10:10

Thank you Clive for your reply.

In the documentation they did refer to the driver being reentrant, I didn't debug STM's driver code yet as I assumed someone here faced this issue before. (as they supplied a sample that only 'usually' works)

ariel2
Associate II
Posted on December 21, 2014 at 23:57

Hello,

I've traced down the error to

Transmit FIFO underrun

(SD_TX_UNDERRUN)

BSP_SD_WriteBlocks-> (5)

sync_window->disk_write

f_sync->sync_window

f_sync->sync_fs

f_sync

Other debug info; Interrupt /Asserts:

  • The FatFs interface SD_write() (in sd_diskio.c) uses BSP_SD_WriteBlocks() _NOT_ BSP_SD_WriteBlocks_DMA().

    DMA and interrupt are not in use.

  • I've enabled asserts in the HAL (stm32f4xx_hal_conf.h, USE_FULL_ASSERT) and in RTOS and added the handling functions.

    When there's an error it does not catch anything..

How can I prevent ''Transmit FIFO underrun''?

 

I've tried to enable ''HW flow control'' but I faced CRC errors which are a

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/SDIO%20Hardware%20Flow%20Control&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=256

.

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/SDIO%2bDMA%20FIFO%20Error%20%28TX%20Underrun%29%20F4%20STM32F417ZGT6&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77...

ariel2
Associate II
Posted on December 22, 2014 at 22:41

[Solved]

I've been able to track down the problem to ''Transmit FIFO underrun'' (in BSP_SD_WriteBlocks).

Apparently it's a

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/SDIO%2bDMA%20FIFO%20Error%20%28TX%20Underrun%29%20F4%20STM32F417ZGT6&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77...

that ''Non-DMA mode'' results in random underrun errors when writing.

In addition trying to resolve it by enabling ''HW flow control'' results in CRC errors (which are also a

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/SDIO%20Hardware%20Flow%20Control&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=256

and are documented in the errata).

I ended up simply configuring the SDIO driver to use DMA, which works well.

(that might lead to another undocumented DMA conflict issue(

http://blog.frankvh.com/2012/01/13/stm32f2xx-stm32f4xx-dma-maximum-transactions/

), but thats a problem for another day :))

Posted on January 09, 2015 at 18:05

Hi,

Once using BSP_SD_WriteBlocks_DMA() instead of BSP_SD_WriteBlocks() you have to ensure that buffers to be written must be aligned. This may reduce the write performance on uSD.

Regards,

Heisenberg.

89maninder
Associate II
Posted on November 04, 2015 at 08:29

hi Jacob,

Can you please explain what was the actual cause for this and what is your fix. I am working on USB FS host. I am also facing same issue of FR_DISK_ERR.

thanks