2014-12-04 05:54 AM
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
2014-12-06 08:27 AM
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>
2014-12-06 01:54 PM
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.
2014-12-16 01:10 AM
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)2014-12-21 02:57 PM
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 .
2014-12-22 01:41 PM
[Solved]
I've been able to track down the problem to ''Transmit FIFO underrun'' (in BSP_SD_WriteBlocks).Apparently it's a
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 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 :))2015-01-09 09:05 AM
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.2015-11-03 11:29 PM
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